In this video from the Red Hat Summit 2018, Chief Security Architect Mike Bursell takes an enthusiastic look at three open source security technologies: DevSecOps, serverless computing, and Trusted Execution Environments.
[youtube=https://www.youtube.com/watch?v=ZNoH4p66m78&w=560&h=315]
These technologies are examples of where Red Hat’s longview is aimed for the security realm.
For Mike, the long-view begins with what is interesting today, what Red Hat is working on, and what he and other security technologists see happening in a future that ranges from a week to more than a decade.
This long-view must also know its own limitations — it cannot predict what will have a future on its own, and it cannot predict what could appear in future open source software projects or products derived from them.
In the video, Mike gives a quick list of items he thinks are very interesting, then asks the audience to vote on which few he will focus on for the rest of the talk:
- DevSecOps
- Remote attestation
- Quantum-safe crypto
- Trusted Execution Environments (TEEs)
- Multi-Party Computation (MPC)
- “Serverless” computing
- Trust domains
- AI/ML & security
From the vote, Mike talked first about DevSecOps, then about serverless computing, and finally about Trusted Execution Environments (TEEs) in relation to the public cloud.
The focus of Mike’s discussion of DevSecOps presents an important distinction to the culture of the related DevOps environment. In the DevOps environment there is a lot of responsibility for knowing how security works placed on the developers and the operators.
The goal, Mike says, is making it more difficult to be insecure, and therefore, “it’s not about making UNDERSTANDING security everyone’s responsibility, but putting in processes (that are) everybody’s responsibility to follow correctly, which will help with that security.”
He shares two examples that are both related to the idea of mapping an organization’s regulatory or governance requirements to a security policy.
In one example, Mike discusses how easy it is for a developer with an eye on the new shiny tool or library to introduce unvetted (unmaintained, unsafe, etc.) code into a codebase. Best practice here is a security policy in the build system to only permit libraries for a specific allow-list.
But it shouldn’t be the developer’s job to choose the most secure or appropriate library to use for the allow-list. What is needed is a stand-alone role to create and own the allow-lists. This role arises away from the DevOps paradigm and is part of moving toward DevSecOps practices.
In another example, Mike discusses work done by Red Hat security developers on OpenControl, which has taken US Government public sector documents and generates a checklist of requirements to use in software development sprints. The checklist is updated as the development proceeds.
One effect is, OpenControl can generate artifacts that can themselves be used for auditing, showing requirements met by particular versions (milestones) of the software as it’s being developed. This allows for security to be baked in and audited throughout rather than jammed in at the front or finish.
Also, developer teams can prioritize security as features to appear in stages of developing software.
The next security topic Mike discusses is the area of serverless, meaning procedures or processes run as a service. The problem, he says, with this type of abstraction is when things go wrong below the serverless level you control, you typically have no recourse to do anything. This comes up in any public cloud.
Due to the abstraction, it is difficult or impossible to respond to security situations.
Mike says, in cloud environments, “There are things we do need to know or we should be asking for, or if we know we’re not getting them, we have our eyes open.”
The risk is if you forget serverless has a server underneath, you can be fooled into thinking there is nothing more to a problem you encounter than ‘point, click, restart’, and not knowing or caring where there is unacceptable risk below the abstraction.
Obscurity through abstraction can be fine for many cases but not for all of them.
The last technology Mike looks at are Trusted Execution Environments (TEEs). A concept first appearing in mobile phones to fence personal and business data, TEEs seek to solve the problem of protecting a virtual environment from it’s host hypervisor or operating system.
Security between VMs is well handled by the hypervisor, and although the risk of VM attacks on the host hypervisor or OS are scary, they are proving manageable in comparison to the risk.
The challenge with protecting a VM from it’s host hypervisor is the types of things you want to protect such as memory are the same things the host needs to manipulate at a granular level to run the VM.
TEEs work on solving this problem by providing a set of hardware instructions that can be used to create a set or enclave of memory for a VM that cannot be looked at or changed by anyone with superuser access on the VM host.
This memory is the only place an unencrypted piece of information is stored, such as financial information or medical records. The memory enclave is able to look outward to engage without being seen into.
There are other potential benefits and downsides to TEEs, which share some similarities and use cases with hardware security modules (HSM).
In summary, Mike reveals that in his relatively short time at Red Hat, he has learned to drive for “more open”. For example, he would want to see work on TEEs done as openly as possible at all levels, not just the Linux source controlling it.
Then Mike shares what he sees that Red Hat can do around security for open source software, essentially to double-down on the principles of open source development. In particular:
- Keep on the fundamentals of providing provenance of source, responding to CVEs, and continuing to build great security-related features.
- Because Red Hat owns the whole stack, continue to think about the stack and security, considering the value and risks of abstraction at the various layers — platform, orchestration, middleware, tooling, CI/CD, Dev(Sec)Ops, and so forth.
- Engage at the business-function level with partners and customers so Red Hat is providing solutions to address risk, policy, trust, and so forth, beyond just the technical and policy arguments for security.
- Continue to do things only an open source company can do, remembering, “open unlocks the world’s potential.”