What’s inside:
“The risky business of software development: five tips for becoming fluent in risk”Resources: DoD’s current Risk Management Framework (RMF) explained, a risk analysis overviewThe weekly brief: A new RMF in the works, a guide to security chaos engineering, and an upcoming tutorial on how to build military-grade authentication
The risky business of software development: five tips for becoming fluent in risk
Ok, we know you’re picturing Tom Cruise sliding across a hardwood floor in his underwear, mic in hand (er, candlestick?). But that’s not where we’re going with this… building software is risky business. And while risk management may not appear in the qualifications for a software engineer job posting, understanding, managing, and mitigating risk is an implicit requirement for dev teams working with the DoD.
First, a very quick introduction to key terms related to risk. As an engineer, an important part of your job is protecting information and information systems. From what exactly? “Risks that arise from the loss of confidentiality, integrity, or availability of information or information systems,” according to the folks at the National Institute of Standards and Technology (NIST).
Here are examples of confidentiality, integrity, and availability:
Confidentiality: Only authorized personnel can access intelligence reports.
Integrity: GPS coordinates aren’t altered by threat actors.
Availability: Secure networks stay online even during a cyberattack. Ironically, well-meaning but cumbersome security controls can also disrupt availability by slowing down authorized users.
Building software always involves risk. Some risks, like a brief service disruption for a rarely-used feature, may be unlikely and have minor impact. Others, such as a data breach from an unpatched vulnerability, can lead to lost contracts, fines, lawsuits, or even put your organization out of business. More critically, you put the mission, and the Nation, at risk.
Five tips for building risk fluency
1. Accept that managing risk is part of your job. In fact, DevSecOps is a method for managing risk, ensuring dev teams are thinking about security as soon as a product or feature is a twinkle in their eye, through planning, implementation, and the entire lifecycle of a product.
Bonus: Once you get past denial and into acceptance, you’ll see that risk management is a creative, cross-disciplinary exercise that often improves efficiency, the user experience, and security.
2. Focus on risk, not checkboxes. Yeah, yeah, we know compliance is not security. Devs need to go deeper, understanding the risk that underpins compliance. For example, you may have to protect the system with multi-factor authentication, but you have some flexibility in exactly how that is implemented to provide flexibility and usability to support your users. In other words, you don’t have to just check a box, you can provide an optimal experience (as emphasized in our recent VIA Knowledge Hub podcast episode with Michael Frank, Deputy CTO for the Department of the Navy).
Bonus: This approach also leads to more productive conversations with compliance leaders and the DoD.
3. Drag risk into the sunlight. Get comfortable participating in cross-disciplinary risk assessments, where you’ll identify risks, score them based on likelihood and impact, and craft a plan to mitigate them. Also, risk assessments are not a one and done, they are an ongoing exercise. In fact, they kind of remind us of Lamb Chop’s Play Along: The Song That Doesn’t End.
Bonus: As an engineer, you bring unique insight into the risks inherent in your system. Playing an active role highlights your value and strengthens your career path.
4. Use the four risk options: avoid, mitigate (reduce), accept, transfer. As VIA’s Vice President of Software Engineering, John Muddle, advises: avoid risk where possible—for instance, by minimizing third-party dependencies. If you only need one dataclass and minimal validation, for example, it might not make sense to install Pydantic. Instead, use Python’s built-in dataclasses. Other risks should be mitigated (or reduced) with security controls. Be cautious when accepting or transferring risk, as these decisions will face DoD scrutiny. The key is knowing your stack, its risks, and being ready to talk about them.
Bonus: Your clients in government will feel comfortable putting their trust in you if they feel you not only understand, but are open and upfront about, the risks in your platform.
5. Shift left. The earlier the concept of risk is introduced in the development process, the more likely developers are to minimize risk as they build software for DoD.
Bonus: Talking about risk from the start moves you closer to the coveted “secure by design” posture.
The bottom line: Trust comes from showing the DoD you understand risk, manage it wisely, and speak about it openly.
Need to know
You have pressing questions about risk…we have answers. So you can move closer to preventing the release of vulnerable code and to achieving a secure by design model. Check out the resources below.
Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy
Who doesn’t feel better when NIST offers up guidelines? The tenets of this framework are a cornerstone of DoD’s Risk Management Framework (RMF). NIST touts it as providing “a disciplined, structured, and flexible process for managing security and privacy risk.” That, they say, includes elements like information security categorization and continuous monitoring.
Risk Analysis - Know Your Threat Tolerance
Still have questions about risk or want a quick video to share with your team? IBM’s no-nonsense, 5-minute explainer breaks down what these terms mean, why they matter, and gives simple examples anyone can follow.
Take note
With all the information swirling around, it’s hard to know where to focus. Don’t worry, we’ve sorted through current headlines, insights, and events and handpicked what should be on your radar for the week.
This just happened
“DOD CIO to Release New RMF in the Coming Weeks”: MeriTalk
In a renovation worthy of HGTV, Katie Arrington, acting CIO at the Pentagon, has been promising to remake DoD’s Risk Management Framework into a Ten Commandments of sorts for software engineers and others doing business with DoD. It looks like Arrington is finally putting action to words, telling an audience at the Billington CyberSecurity Summit in Washington that new guidance that “retains strong cybersecurity standards without sacrificing speed and innovation” will be landing in the “next couple of weeks.”
Worth your time
The Basics of Software Resilience and Security Chaos Engineering
All this risk talk can make your eyes glaze over and makes you lose sight of what the ultimate goal is: to build more resilient systems. Kelly Shortridge’s book Security Chaos Engineering: Sustaining Resilience in Software and Systems offers a great introduction to the principles behind resilience and systems thinking, including the helpful reframing of “treating resilience—security included—as a product.” This blog post overview of her book is an excellent resource for engineers.
Don’t miss this
Later this week, check out the tutorial “How I built military-grade authentication in five minutes (and why your users will love going passwordless)” from Jesus Cardenes, VIA’s Senior Vice President, Product Architecture.
