It’s the fourth and final quarter of 2021, believe it or not. That makes it time for IT leaders to review and evaluate how things are going – and plan for 2022. Security sometimes gets left out of those conversations. We’re here to make sure that doesn’t happen, with an extensive list of questions worth asking as you assess your security posture and look for ways to improve.
We’ll start with a series of topics that are particularly relevant for teams that are considering or already implementing a DevSecOps strategy, then we’ll cover a series of fundamental questions worth asking in any organization – especially those currently struggling to modernize their security approach.
[ Want a shareable primer on DevSecOps and its benefits? See What is DevSecOps? ]
Your security strategy: 11 questions to ask now
Let’s dig into 11 questions (and then some) worth asking about your security strategy.
1. Why are we talking about DevSecOps?
The tone and subtext of this question (and its answer) could be entirely positive and productive: Why are we talking about DevSecOps? To clearly define our reasons and goals for embracing it. (That’s a great answer.)
It could be “blissfully” ignorant: Why are we talking about DevSecOps? We already have a firewall and antivirus software installed. (Welcome to 2021! Times have changed.)
It could also be more reasonably skeptical: Why are we talking about DevSecOps? We’re already a DevOps shop. (We get it: Let’s explore this a bit.)
“DevOps, done right, already includes a security focus,” says Terumi Laskowsky, a Hawaii-based IT security consultant and cybersecurity instructor at DevelopIntelligence.
Automated CI/CD pipelines, a DevOps cornerstone in many organizations, should already include extensive code, QA, and security testing. Why are we talking about DevSecOps again?
“In the effort to speed up the entire DevOps process, security is often left behind,” Laskowsky says.
There can be many reasons for this, but she points to two big ones. First, the company or team wasn’t prioritizing security in the first place. “This means instead of producing vulnerable software every six months, they are now releasing vulnerable software every six hours,” Laskowsky says.
Second, security tools were often laggards in terms of automation, which meant they got left out of CI/CD pipelines. “If companies wanted to do security testing right, they had to stop the process and conduct it manually, undermining the faster, more often paradigm of CI/CD,” Laskowsky notes.
As a result, otherwise high-performing DevOps teams can find ways to delay and deprioritize security while deploying faster and more frequently, which inherently increases risks. Laskowsky notes that DevOps teams can move security features to later sprints under the guise of “refactoring” process to “improve the code later.” This is not the original intent of refactoring, she points out. (The more accurate term for this practice: technical debt.)
DevSecOps seeks to course-correct where security is subtly (or not so subtly, as Laskowsky says can be the case) left behind as the rest of the organization achieves the promise of DevOps culture and practices. Security tooling is catching up with APIs and other automation enablers, too.
“DevSecOps seeks to put focus on security and make it a legitimate and essential part of DevOps,” Laskowsky says. “That means organizations automate security testing, incorporate security functions from the start, and secure the CI/CD pipeline infrastructure as well as the artifacts.”
[ How can automation free up more staff time for innovation? Get the free eBook: Managing IT with Automation. ]
2. What are we doing to build a healthy security culture?
This is a big question: Even the framing is deliberate, in that it reflects the multiple dimensions and ongoing commitment required for a strong security culture that grows throughout an organization. Just saying “we do DevSecOps” without backing it up is a precursor to trouble.
As Red Hat technology evangelist Gordon Haff recently told us, people and culture are typically the most overlooked components of DevSecOps; all of the tooling and process optimization in the world won’t make up for that omission.
Here are some examples of intersecting areas that a positive answer to the culture question should cover:
Budget: Are you asking your security teams to undertake significant effort and change without giving them the resources and tools they need?
Security IQ: Are you asking people and teams outside of the immediate security realm to be able to identify risks and threats? How are you helping them build knowledge?
“Technology changes at a rapid pace – security even more so,” says Sean Wright, principal application security engineer at Immersive Labs. “As such, it is vital that employees have access to and can carry out periodic, hands-on training to ensure that they keep their knowledge, skills, and judgment up to date.”
Speed and security: Per the first question: Are you giving security the wink-and-nod treatment while focusing solely on faster and more frequent deployments? The mission and support to do both must come from the top, Laskowsky says, including a shared understanding that in the early days of DevSecOps, there might be some temporary slowdowns in the CI/CD pipeline as new tools, processes, and teams become integrated.
“Asking for ‘faster’ on the one hand and ‘more secure’ on another may be a tall order,” Laskowsky says. “If businesses only reward speed and not security, guess what you will get?”
3. Where does friction exist between security and business goals?
The question is relatively self-explanatory: DevSecOps exists in part to remove friction and bottlenecks that have historically introduced risks rather than reduce them. The question also has a subtext: What are we doing about it?
This friction often goes unaddressed because, well, it’s unaddressed – as in, people avoid pointing it out or talking about it, whether because of poor relationships, fear factors, cultural acceptance, or other reasons. Leaders need to take an active role here by showing their willingness to talk about it, without finger-pointing or other toxic behaviors.
“Leaders should constantly be probing and trying to understand the friction points between the business and DevSecOps,” says Jerry Gamblin, director of security research at Kenna Security, now part of Cisco. “These often uncomfortable conversations will help you refocus your team’s goals on the company’s goals.”
A willingness to have those uncomfortable conversations as a pathway to positive long-term change is a key characteristic of a healthy culture. If it doesn’t already exist, re-read #2 above and then add it to your to-do list.
Gamblin also suggests a related question for security teams: What’s slowing us down? (Note: If you’re just starting out with security automation and other facets of DevSecOps, expect slowdowns. It’s the long-term or permanent bottlenecks you want to find.)
“This is a great question that often will get at the root of what you need to work on in the next year and, more times than not, will lead back to a policy or procedure inefficiency rather than a technical issue,” Gamblin says.
It’s a good way for leaders to make sure they understand their team’s pain points and remove artificial or otherwise unnecessary obstacles. It may also be a good way to generate new possibilities for automation, both in security and in other processes.
4. Do our security metrics accurately portray performance?
“Measure everything” is both the title of a popular leadership book and a general principle in a data-driven organization. But it doesn’t usually mean you care about every metric equally (or at all, in some cases). It also doesn’t mean every number speaks for itself: You need to review and interpret your quantitative metrics within your broader organizational context.
“It’s always important to step back and reflect on what is and isn’t working, so the very first thing you should do is look at your metrics,” Wright says. “Do they genuinely reflect the current risk your organization faces?”
Things change over the course of a year; heck, in security, they can change in the course of a day. Reevaluate your metrics – and the context in which you’re interpreting their meaning – to ensure you’re staying current and developing an accurate picture of where things stand.
[ Also read: OKRs and KPIs: 6 counterintuitive tips for leaders. ]
Wright uses “average time to patch a vulnerability,” broken down by severity, as an example. This tracks how many new vulnerabilities have been introduced or discovered in a given timeframe – and how long it took to resolve them – to create a snapshot of your security posture.
This is also a good example of the need for context: If you’ve embarked on a DevSecOps initiative recently, more vulnerabilities – and even a longer time to resolution – aren’t necessarily signs of poor performance.
“Don’t despair if they appear to be getting worse – it’s not necessarily a bad thing, as it could just mean your team is getting better at finding more things,” Wright says.
Wright also points out that you can revise the same fundamental question in various ways that may produce different answers or signals:
-
How did our annual penetration test compare with last year’s?
-
Have more vulnerabilities been introduced by development teams?
-
Have more vulnerabilities been introduced by our operations/DevOps teams?
-
How many vulnerabilities have been fixed? How does this compare to the number that were raised?
-
How long does it take to resolve a vulnerability? (Break it down based on severity as well as department.)
-
How often are developers logging into tooling and reviewing the results?
The goal isn’t to assign blame but to create a meaningful context for shared metrics and responsibility and in an environment characterized by constant change. Real-world security is never static; how you measure performance and assess risk shouldn’t be either.
5. Have our security policies and tools kept up with the way people work?
While specific industries such as healthcare continued to require significant in-person operations throughout the pandemic, many businesses pivoted to fully remote work. That might have seemed like a temporary solution in 2020. In 2021, remote and hybrid work models morphed into long-term operational plans.
If you haven’t reviewed your security stack and policies accordingly, then no time like the present. If you’re considering or implementing a DevSecOps model in parallel with codifying your hybrid/remote work model, all the better.
[ Related read: 9 DevOps and DevSecOps best practices for the hybrid work era. ]
“Now is the time for IT and security stakeholders to examine what their current mix of cloud [and] on-premises resources look like and how they anticipate this will evolve in the future,” says Amit Bareket, CEO and co-founder of Perimeter 81.
Naturally, cloud infrastructure and services usage has generally been on the upswing as companies have worked to ensure that remote and hybrid teams can work effectively from home or any other location outside of the traditional workplace. That means it’s a good time to review policies and controls – even if you already did so when everyone pivoted to WFH last year – governing resource access, user privileges, cloud configurations, and so forth. Bareket suggests taking a long look at a Zero Trust model if you haven’t already, for example. Granularity, visibility, and automation are all key in hybrid and remote operations; the same is true for DevSecOps.
If you anticipate bringing new systems and services online to support a hybrid or remote workforce – and/or to support your DevSecOps strategy – then make sure you’re factoring them into your risk assessments and general security strategy. Bareket also notes that IT leaders would be wise to watch out for tool sprawl as they continue to adapt and plan for hybrid and remote operations: It’s another possible threat vector.
“What are the additional resources or services their organizations will be acquiring and how should access to these resources be monitored and secured to avoid any harmful data breaches?” Bareket says. “All of these considerations can be key in laying the groundwork for a sound and secure 2022.”
6 more security questions to refocus on the fundamentals
All of the above can be useful for thinking about security in any organization, but the questions are particularly focused on teams already doing work to modernize their security operations, whether under the DevSecOps/DevOps banner or otherwise.
Laskowsky shares six more questions that can serve two broad purposes. First, they’re examples of rechecking on the fundamentals at year-end (or any other timeframe as you see fit), even if you’re a mature DevOps/DevSecOps shop. Second, they can help you identify issues and weaknesses if you’re trying to make the case for a bigger commitment to security – from budget to staffing to silo-busting and more. Think of these as probing questions that might also answer question #1: Why are we talking about DevSecOps?
“Shortcuts, bolt-on security, insufficient monitoring, and inadequate workforce vigilance all contribute to increased cybersecurity risk,” Laskowsky says. Answering these questions can help tell that story:
- What security compromises have we experienced this year, how much did these cost us, and what were the causes?
- What steps have we taken to make sure the compromises in #1 don’t happen again?
- Is security baked into the full SDLC and our business processes? Or is it “bolted on?”
- Are we taking security shortcuts to get features out the door faster? If so, is our risk management team aware of and on board with these shortcuts?
- Are we adequately monitoring and testing for security vulnerabilities?
- Are we keeping security top of mind in our workforce?
Questions framed as “Are we doing X?” might lead to simple “no” or “I don’t know” answers. In either case, there’s work to do – but you can also revise them with “What are we doing about X?” or “What can we do about X?” to see if they produce different responses. (Again, if the answer is “nothing” or “I don’t know,” that’s still a signal of work to be done.)
“Life tends to give you more of what you concentrate on,” Laskowsky says. “Asking questions about DevSecOps and incorporating it into the overall IT strategy planning are excellent steps towards improving organizational cybersecurity.”
[ How do containers and Kubernetes help manage risk? Read also: A layered approach to container and Kubernetes security. ]
