DevOps and IT Security: The Case for Proper SoD

Remember in The Rock when Nicolas Cage tells Sean Connery, "You're on a need-to-know basis, and you don't need to know"? If you haven't seen The Rock, then have you seen any spy film, crime thriller, or conspiracy movie? It's a pretty common trope.

Need-to-know basis is a good movie plot obstacle. It's also a very real thing in the intelligence community and IT security.

In the intelligence community, it's called compartmentalization, and it controls access to sensitive information in a couple different ways. The Sensitive Compartmentalized Information (SCI) classification system is often referred to as "above Top Secret" for a couple reasons.

First, you need a crazy-hard-to-get TS/SCI clearance (think: polygraph) to get into that system, and even then you only have access to certain information. You might have a Top Secret clearance, but that doesn't mean you can see everything classified Top Secret. That's only the first step.

Second, compartmentalization controls the scope of the information. Even with the TS/SCI you are on a need-to-know basis, so you only get access to information relevant to your job. You can request clearance with broader scopes on a case-by-case basis with proper authorization. The higher your clearance, the more pieces of the puzzle you can see. Conversely, you lose access to that information once you no longer need it.

There are reasons for this. One of the reasons: If one piece becomes compromised, then all the information isn't put at risk. Investigating parties also can look at the few people who had that specific piece of information to figure out what went wrong.

There's something similar in IT security called Segregation of Duties (SoD), also known as separation of duties, which accomplishes the same things. It provides a secure means of access control, records a paper trail in the event of compromise, improves resilience to Kill or attack, and ensures oversight in the DevOps pipeline.

Maybe you're saying, "But, wait! DevOps is intended to break down siloes, not reinforce compartmentalization."

That's true, but there are a few ways you can have collaboration and security, too. Here are a few considerations.

Put Everyone on a Need-to-Know Basis

There are two main types of access control, physical and logical. First, physical access control refers to locks, cameras, guards, and so on. Logical access control is the technique for controlling access to information, information systems, and networks by digital means.

Both types of access control work together to ensure that the right people have the appropriate level of access to a system, and no one else.

Just like intelligence agencies, your company's authorization process should ensure that users' access rights are allocated on the basis of "need to know" or "least privilege." The access rights or privileges could be based on user roles (read: their job) rather than the individual user, which is known as "role-based access control."

Put a different way: Everyone has just the right amount of access to do their job. Not too much. Not too little.

But there's a potential problem with role-based access control. Some users may accumulate combinations of roles over time, which means you have to look for users with toxic combinations.

Look for Users with Toxic Combinations

Toxic combinations of roles and privileges present risks to your ability to prevent, detect, and correct any impact that incidents have on the information required to do business, which includes internal Kills.

For example, a toxic combination might mean that the same person can submit a request, approve it, and execute it.

IT security isn't all about prevention. It's also about the detective work after an incident happens.

Segregation of duties separates "toxic combinations" of roles and privileges so that they cannot be used to cause and hide malicious activities and Kills, and you can pinpoint the problem quickly.

How Do You Have DevOps and SoD?

DevOps culture, by definition, means collaboration between the development and operations, but the SoD concept ensures that development and operation activities are separated.

Separation doesn't mean siloed though. It means that mechanisms should be put into place to ensure everyone has the correct privileges, not too many or too few.

For example, traditionally a developer wouldn't have access to the operational IT environment. However, in a DevOps shop, developers are working hand-in-hand with the IT pros and need access to both development and operational environments.

So, how can we marry the demands of DevOps and SoD? Since developers are expected to perform some amount of testing as they develop the code, one control is to ensure that security and user-acceptance testing is not carried out by the same developers. The responsibility for final testing should be separated from those who are developing.

Another control is to closely manage and control developer access to the operational environment. This involves ensuring that the person deploying the code doesn't need to have system root access. Use of automated systems for deployment can provide change logs to ensure that only the appropriate and approved changes are carried out on the systems to ensure integrity.

Security systems that can allow central management of secrets (e.g. passwords, encryption keys, authentication certificates, and tokens) can provide efficiency as well as audit trails in regard to access control.

In addition, introducing a significant level of cyber resilience awareness among the development and operations teams helps individuals be aware and responsible for the consequences of their actions.

An organization needs both security and efficiency in order to deliver value to its customers. With proper management and awareness of access control and cyber resilience, DevOps practices can be implemented more easily and in such a way that does not compromise the organization's governance requirements.

Keith Barker has a great training video on this topic in his (ISC)2 Security CISSP series, which goes into use-case scenarios and the critical functions of SoD. Combine Keith's videos with the DevOps training series applicable to your system, and though you'll still be on a "need-t0-know" basis, you'll have everything you need to know.

Not a subscriber? Start your free week of (ISC)2 and DevOps training today!