1. Software is broken. It’s created broken, it’s delivered broken and what’s worse, users become (unwitting) beta testers. These flaws in the delivered product result in vulnerabilities which are exploited by hackers and malware authors. In a disturbingly large proportion of cases, the delivery of flawed products can be traced to the nature of the software development life cycle itself. In these cases, security verification and validation is the penultimate step prior to release. As a result, it’s often rushed, resulting in flaws not being discovered. Worse, it’s often too late or too expensive to fix a significant number of the flaws that are found.
But what if security verification and validation could be pushed back to the beginning of the development lifecycle? If we could ensure that the only code modules that entered the trunk were those that had passed the complete battery of functional and non-functional (e.g., performance, scalability, interoperability and security) tests, the ensuing increase in the quality of software products would be accompanied by a significant decrease in delivered vulnerabilities.
The good news is that this is exactly what the DevOps PaaS delivers. By leveraging a shared, Cloud-based integrated development environment (IDE), environmental variances between Dev, Test and Operations that inject vulnerabilities can be eliminated. Next, by automating DevOps practices such as Continuous Build, Continuous Integration, Continuous Test and Continuous Design, the onus is shifted to the developer, who must deliver flawless code, from the tester who had previously been (unrealistically) expected to find all the flaws in the code.
2. Many, if not most, critical systems are protected by access control systems that focus on authentication, or ensuring that the entity requesting access to the system is who it claims to be. Authentication can be a powerful gate guard, sometimes requiring multiple concurrent methodologies (e.g., something you know, something you have, something you are, etc.). The problem is that once a user is authenticated, these systems provide few, if any, controls or protections to system resources. This vulnerability was exploited by both Bradley Manning and Edward Snowden.
The answer is to add a layer that enforces fine-grained authorization and managing which resources can be accessed by authenticated users with a given set of attributes. This mechanism, called attribute-based access control, or ABAC, is implemented through an OASIS open standard known as the eXtensible Access Control Markup Language (XACML). XACML was first published in September 2003, and there are a significant number of commercial software packages (both proprietary and open source) that use it to bring ABAC’s powerful security to the enterprise.
3. When vulnerabilities are discovered in an enterprise’s key software components, it can take a significant amount of time to disseminate countervailing security measures. During this time, the enterprise remains vulnerable. The challenge is to rapidly close the security gap while ensuring that the enterprise’s operations suffer as little disruption as possible.
The answer is to apply access control security at the operating system level, enabling an access control regime that is dynamic and centrally controlled. In principle, this is similar to what ABAC implements for enterprise resources. In this case, however, the control takes place at the inter-process communication (IPC) level. In practice, this means that the organization can, upon learning about a vulnerability or compromise, push out a new access control policy to all hosts. The policy can both enable and disable specific IPC types. The net result is that the compromised software is prevented from executing while replacement software is seamlessly enabled.