If you’re involved in transforming your organization to be more agile or responsive to digital initiatives, you’ve heard the term ‘shift left’ a lot in the past couple of years. What does it mean? Why does it have to happen? Could this lead to disaster down the road?
Begin at the Beginning
Shifting left refers to the visualization of a software development cycle. Because people in the Western world read books left to right, the diagram is ordered left to right. I found a great example of this at this Medium post. Here’s the diagram:
If you’ve ever written software or even done any project, you no doubt recognize these steps. These steps are an orderly way to build something. You plan, you build, you finish, and then you operate and maintain.
The development world is focused on combining these diagrams as much as possible, so the teams that operate are as involved in the development as anyone else. This gives rise to (you guessed it) DevOps. One group working together to accomplish things.
This diagram also illustrates a specific problem with security when it comes to software development. Where should we worry about securing things? The correct answer is ‘everywhere’, and that’s the answer you would give when someone asks you. However, where does it happen, if at all?
The mantra of many developers on the new breed has been ‘Move Fast, Break Things’. I would posit that we need to add ‘Secure It Later’ to the end of that statement. It’s not uncommon for developers to put the bare minimum of security controls in a program to aid in fast development and then forget about it until a point in the cycle where removing those crutches is all but impossible. Security should be a part of the initial workflow but feels like an afterthought more often than not.
Policy is Pertinent
Now we know about the problem. How do we fix it? The answer is deceptively easy and challenging at the same time. You need policies. This is the quick response but the hardest thing to implement. You’re already doing it, though, without realizing it. But, you need to get better at it.
Let me give you a quick example. Do you code your apps in FORTRAN? Assembly? Do you write your Python code with all-caps variable names? Are you forbidden from leaving comments in code? These all represent policies that your organization has adopted. There’s likely one or two languages to build in depending on the application. It must support a login or have obfuscated credentials. Your variable names must meet a certain standard, so the code isn’t littered with foo1 and bar48 everywhere.
Policies ensure that you are doing what needs to be done without being able to violate the constraint. Let’s take a car as a typical example. There are speed limits on roads. This rule is often violated for a variety of reasons, some good and some not so good. Most American automobiles have a device that prevents the engine from gaining speed above a certain amount, such as 110 MPH. This governing device is a policy that says, at least in America, no one operating that vehicle has a reason for driving that fast. It’s a safety issue to the manufacturer, so they installed a policy enforcement device to prevent you from violating the threshold. They could easily install a governing device to prevent you from breaking the speed limit for your region, but that would cause a massive amount of pushback.
Policy is the same for software development and security. Developers will fail to implement security if they are allowed to avoid doing it, just like people will refuse or fail to change passwords unless they have an expiration date or are forced.
Policy in the development cycle ensures that you can enforce these rules and guidelines from the beginning. If you have a policy that AWS API keys are never stored in the application code, then an enforcement system can check for the API key and prevent it from being saved even for a moment. The enforcement trains proper security behavior from the start instead of hoping that someone will come along later to fix it before it breaks.
Training with Cisco Tetration
Creating good security habits through policy is a thing we should strive for. How can we accomplish it? During Security Field Day 4 last year, Cisco showed off how they can use their Tetration analytics platform to create and enforce policy for application developers. Remi Phillipe did an excellent presentation about it.
Here’s the video if you’re curious to see a great demo:
Policy checking doesn’t have to be hard. Something as simple as looking for a file that already exists and creating an error message if it is a policy. Those policies are building blocks that can lead to enforcement at all levels. Suppose you have a policy that says that you have to call an authentication system for password validation. In that case, you can embed that policy in various checks to ensure that passwords are not being hard-coded into the software during the build. It sounds crazy, but some people will take those kinds of shortcuts to make something work and then promptly forget about it until it’s a massive problem during operations.
Likewise, tools like Tetration allow your policies to be agnostic of changes in the organization. Suppose you have a tool set up to scan Python code for security errors, and your organization changes to Go or Rust or even COBOL. In that case, you’re going to need to rewrite that tool to check those new languages and hope that no one ever writes in Python again. With Tetration, you’ve already defined the policy. The platform can incorporate enforcement into a new language or process and ensure that it’s carried out no matter what. It also ensures that older code is still enforced. You’re protected no matter who is writing or what they’re writing with.
Bringing It All Together
DevOps and DevSecOps want to move fast and ship code and features to keep users happy and productive. But that doesn’t mean they should be moving so fast as to create security problems. Violating the speed limit by a few miles an hour to save time is not good, but racing down the street at 100 MPH is much worse. Moving fast, with no regard for safety and security, will cause problems. Thanks to tools like Tetration that help you build and enforce better policies along the way, you can ensure that your DevOps groups and app developers are moving as fast as they can safely go without leaving security behind.
For more information about Cisco and Tetration, make sure you check out their website at http://Cisco.com
