Incorporating The 'CIA' Triad In Software Purchases
When talking to sysadmins and developers about security of the new software they're looking to deploy, I often end up in a discussion in which at least one or two of the CIA (confidentiality, integrity, and availability) triad is left out.
When talking to sysadmins and developers about security of the new software they're looking to deploy, I often end up in a discussion in which at least one or two of the CIA (confidentiality, integrity, and availability) triad is left out.I'll admit that I'm often the one who forgets about availability, but that's because that angle is often being covered by someone else -- usually the sysadmins. That still leaves confidentiality and integrity, which are plenty in their own right, yet one or both are often overlooked without a second thought.
By now, we should all well understand the confidentiality aspect of the CIA triad. It is typically the primary focal point of "keeping data secure," yet a quick peek at some of the recent breach headlines, like the one belonging to T-Mobile, is enough of a reminder that it's being handled poorly. I've seen it repeatedly, where lack of thinking about the big picture during simple tasks, like software purchases, ends up being the root cause of a breach.
A good example of "missing the big picture" happened recently when I was asked to take a look at a piece of software a client was considering for use in its business. The concern was the software would be part of a system that interfaced with some data that would have dire consequences if ever leaked. Since this data was integral to operations and affected every one of its customers, it was critical that data not be exposed nor be modified in any way.
After digging up as much about the product from the vendor's site, I started talking with my client's admin, who was asked to install the software as part of the initial testing process. He had some concerns about how the product integrated with the database and the level of access needed compared to similar software the company had reviewed. We contacted the vendor, and the response was we could limit the extent of damage to the data if the software was exploited by creating a read-only account for its software to use.
Great! Here we were concerned that its software had access to every bit of the database server, yet it was providing us with a solution that prevented our data only from being deleted or modified. Management is still pondering what to do, but considering that the software is going to be on a Web server and will have access to the critical data that makes this business money, I'm hoping this product goes to the bottom of the list and that the client continues to look at alternatives.
Have you ever been in that situation? Which won out -- management's desire for functionality, or the need to data security? And how have those decisions changed during the past few years as breaches became more common in the headlines? Let me know either by e-mail or the comment form below.
John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.
About the Author
You May Also Like