This blog is the last in a series of cyber security insights for National Cyber Security Awareness Month, recognized each October. In this fourth blog, MediSked Senior DevSecOps Engineer Nathan Westerman shares his unique perspective on why agencies looking for a software solution should look for a company with a DevSecOps team.
I work on a dedicated DevSecOps team at MediSked. DevSecOps is a portmanteau of Development, Security, and Operations, and our team exists to bridge those three worlds—to “shift left” by empowering developers to have more autonomy, agility, and ability to catch defects in security and quality earlier in the software development lifecycle. The formation of this team earlier this year is one of the ways that MediSked is working to be the leading brand in holistic solutions that improve lives, drive efficiencies, and generate innovations for health and human service organizations that support our community.
Empowered developers are more efficient and have a greater ability to innovate quickly. The end goal is for the team to be so effective that DevSecOps moves from being a team to being a mindset that we all have. That’s when the developers will have been truly empowered.
When I told my teenage daughter I was planning to write about cybersecurity, she was less than enthusiastic about the topic. This, much to her chagrin, did what it always does when I think I have a “dad teaching moment”: it prompted a discussion. During that discussion, it came out that she knows security is important but that she trusts me to keep her secure. I am her dedicated cybersecurity team. It’s great that she knows how important security is, as I’m sure we all do, but that’s not enough. We must make it an integral part of our digital efforts. We must learn to fish for ourselves lest we stay dependent on specialized security teams to supply security fish to us.
Before I continue, I just wish to be clear that I am not suggesting that we all need to be cyber security experts. Cybersecurity experts are a great resource that I am grateful exist because there are new security threats being made every day and it is unrealistic to expect every developer to be an expert on every threat. We do not all have to be able to recognize and know how to catch every kind of fish that is in the sea, but we all need to know how to tell which are safe to eat without having to check with the experts every time we’re hungry.
Most of us work for places protected by cyber security teams, and I am sure most teams are like mine: full of great people trying their best to protect all your company’s digital secrets. A lot of places treat their cybersecurity teams the same way the Men in Black’s motto dictates, that they are “the first, last, and only line of defense against the worst scum of the universe.” But that’s not realistic, cannot scale, and is destined to fail.
I’m sure we’ve all been on teams where the process required the security team to have manual hands-on involvement with every change, and that process was, at times, interminably slow because the cybersecurity team was inundated with so many requests due to the imbalance of the number of developers compared to the number of cybersecurity team members. No matter how awesome our security teams are, they are still human and can only do so much before their human limits are reached. Once that happens, more is needed from them than they can scale to supply, and security, as important as we all know it to be, starts to take second stage to the need for greater and greater productivity.
Unfortunately, it’s not uncommon for businesses to see security as an unwelcome burden rather than a partner in delivering high-quality products to customers. However, it doesn’t matter how great all the fancy features are, with the flash and pizazz, if random people on the internet can run simple cracking tools and get access to the confidential data of your customers.
Breaches are expensive, and the threats are expanding all the time as software systems get more complex and more integrated into every aspect of our lives. Cybersecurity teams, being only human, cannot be a company’s only line of defense. This is where DevSecOps comes in, helping to make security a part of everyone’s job, rather than just the cybersecurity team.
Tasks can be automated, and it is through that automation that true scale can be achieved. In scenarios where budget or time constraints don’t allow for automation, processes can still be reevaluated and altered to improve the workflow. At its core, DevSecOps is an attitude of evaluating processes to make them most efficient, to catch quality and security issues as early and as cheap to fix as possible. This attitude can be applied to bottlenecks, and it should be able to bring great benefits to your company.
Let’s look at some things that can be done to bring DevSecOps and its benefits to a software company.
1. Security training
“Knowledge is power,” they say, and “they” are right. Training the developers and testers of a company in security concepts will pay big dividends long term. Developers will learn to recognize insecure patterns before they have even finished writing them, and testers will be better able to recognize signs of insecurity and can test for it. This training should cover the basic things like using strong passwords, using password managers, locking computer screens when leaving their desks, and not letting strangers into the building, no matter how nice they seem. That training is important, and failure to know and follow those kinds of basic rules can often lead to security breaches.
In addition, training focused more specifically on application development should be supplied. The training should be focused on the type of applications your company develops. For web applications, a good solid start would be training on the OWASP (Open Web application Security Project) Top 10, “a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications,” and I agree with their claim that it is “Globally recognized by developers as the first step towards more secure coding.” If you work at a software company that doesn’t already have a chosen training provider, many of the online training sites such as Pluralsight and Udemy have courses, and there are some great OWASP Top 10 courses on YouTube as well. In addition, as the security team becomes aware of new threats pertinent to the company, they can share them with developers and testers.
GI Joe correctly claims that “Knowing is half the battle”, and training is a great first step, but it is not good enough to stop there.
2. Automate application code review
Security teams are often tasked with reviewing the changes that the development team would like to release. Aside from the scaling issues previously discussed, another issue is that it usually happens after all the code is written and maybe even testing has been completed too. This means that any issues security finds will require re-work, possibly wasting significant amounts of already invested developer and tester time. Also, this can create an adversarial attitude between development and security, with security being viewed as an obstacle to being “done.”
An automated code scanning tool, usually called a SAST (Static Application Security Testing) tool, can be acquired and provided to developers so that they can scan their code as they are developing it, or right after. Cybersecurity experts can ensure that the correct things are being looked for by the tool so that their domain knowledge can be applied in a scalable way any time the code needs scanning. Because it is now so scalable, scans can be run at development time and whenever the code is integrated back into the main branch. There are paid options (such as Checkmarx CxSast or Snyk) that come with a lot of guidance and support, and if the budget doesn’t allow for that, there are plenty of good open-source or free options. A good starting list of some of those options can be found here.
3. Add security to the manual peer code reviews
Most development shops have some sort of peer code review, and adding security as an item the reviewer looks for is an easy, scalable step. If they have the automated code scanning tools that were previously mentioned, then they don’t need to look for the things that the scanner can find, but instead, the reviews can focus on things not as easily detected automatically. An example could be proper access controls, such as whether the developer making sure that user Fred is allowed to even look at the results of a query, for instance.
4. Automate application security review
SAST tools and peer code reviews can catch a lot, but some things are best found when the application is running, and for that, there are DAST (Dynamic Application Security Testing) tools. These tools are designed to interact with your application while it is running in a test environment (it’s particularly important that it not be a real environment, trust me) and try to do all the sorts of things that would be attempted by malicious actors trying to breach your application. These tools can be automated to run at specific times, or phases in the code delivery pipeline. Like the SAST tools, DAST tools have a lot of paid options (such as Tenable or StackHawk) with support, or free and open-source options. A good starting list of some of those options can be found here.
5. Utilize infrastructure as code and IaC scanning tools
Another common task for security and operations teams is creating new infrastructure to run applications and reviewing that infrastructure for security compliance. This is often a very time-consuming manual task, and an area rife with opportunities for improvement with DevSecOps practices using IaC (Infrastructure as Code). IaC allows the application infrastructure to be defined using code or markup and version controlled. By defining infrastructure, you get repeatability, so an operations team member is no longer required to manually click around a cloud provider’s dashboard to create what the development team wants. This code can even be automated so that, when committed to source control, it is automatically deployed. The developers can write the code for their infrastructure themselves. Depending on a company’s needs and environment, IaC can be implemented with tools like Terraform, AWS (Amazon Web Services) CloudFormation or CDK (Cloud Development Kit), or Azure ARM (Azure Resource Manager).
With that great power comes great risk of accidentally introducing defects, so automated IaC scanning tools should be put in place to make sure all the infrastructure code the developers create follows the security best practices the security team has declared. This allows rapid innovation from development while staying within secure guard rails. For example, they should be able to make S3 buckets but should not be able to make publicly accessible S3 buckets, and the IaC scanning tools can enforce that. As with the other tools, there are paid options as well as free and open-source options. Some options in this space include Checkov, CloudFormation Guard, and Checkmarx kics.
Security, like Ogres, onions, cakes, and parfaits, is all about layers. No one layer will catch everything, but all these layers together should allow issues to be caught as close to development time as possible, and not when during the yearly penetration test, or worse—when a breach occurs.
These changes are some great ways to get started on the exciting journey to improving security and quality with DevSecOps, but it is not an exhaustive list.
Remember, we are all on the same team, we all have the same goals of delivering high-quality software to improve the lives of our clients. Let’s work together, get creative, and solve problems.
