Security versus Security: When security requirements conflict
One of the topics I spend quite a bit discussing in this space is the conflict between security and functionality. Often we are forced to make a choice between them; if we allow people to post anonymous comments to our site giving more functionality to more people, but we run the risk of malicious users exploiting our site. That is the traditional security versus functionality dynamic. But sometimes security isn’t nearly so clear cut. I thought it would be fun to explore a situation where the conflict is security versus security.
Consider data in transit. We want to ensure that the data in transit is not vulnerable to man-in-the-middle attacks, and that the data is being sent only to authorized individuals. Both of these are required in order for us to protect the confidentiality of the data. To fix the first issue we may opt to encrypt the data, to prevent prying eyes from reading the data. But by doing so we also ensure that the “good guys” can’t see it either. We can no longer monitor which data is going where. Conversely, if we set up monitoring to track which data is going where, we have to leave the data in clear text, available for eaves-droppers.
We can implement technologies that will temporarily decrypt the data for our monitoring then re-encrypt it and send it on its way, but even a short decryption period will allow more eyes access to the data. Even the best technologies need to decrypt the data to perform their inspections. It’s during that unencrypted period that the information is vulnerable. In the end, we simply can’t have it both ways. In order to protect the data in one way, we need to leave it exposed in another.
For those of us who are tasked with protecting an organization’s most valuable information, this is a scary fact. There is no way to eliminate all risk. Start your worrying, right?
Not at all. This is an opportunity for us to practice what we preach. This type of risk management is a primary difference between IT and InfoSec staff. Just as the business has to take a hard look at what risks they are willing to accept and which we need to pay to mitigate, the security department needs to carefully inspect which vulnerabilities are the most severe and require remediation.
This challenge offers us a couple of valuable opportunities that are unique to information security.
As we perform the risk calculation between our own two objectives, we eliminate the “us versus them” philosophy that surrounds so many security conversations. So often when we bring up a security concern with the business it becomes a battle to see which team has the power to get their way. At that point we’ve stopped working as partners striving to meet the objectives of the organization. We’ve forgotten our mission.
As we have experienced in the choice between encryption and monitoring, just because there are two perspectives doesn’t necessarily mean there are different objectives. We must work with our IT and business partners in a way that emphasizes that we have the same end-goal. We can build these bridges if we discuss our common objective and work to find consensus on the best way to achieve it.
Just because there are two perspectives doesn’t necessarily mean there are different objectives.
This situation also presents us with the opportunity to dig deeper into the objectives and requirements of our business. To be done right, these risk decisions must be made with full visibility into the business impacts, total costs, human and technical resources, and organizational risk appetite. Don’t settle for being an expert in information security systems and theory. We must also be experts in the business of our organization.
Next time an information security expert tells you that a system is secure ask him, “What kind of secure?” We know that choices are always made and vulnerabilities always left unmitigated. Knowing which ones to address and which to accept is what makes a security program effective.
Connect with Robb on Google+