Secure Software Development, Documentation, and the Biden Administration’s Latest Cybersecurity Directives


September 28, 2022

What Your Organization Should Be Doing Now

Lexie Nelson- Secure Software Development


By now, many of you may have heard about President Biden’s September 2022 cybersecurity directive. Simply put, it requires government vendors to create documentation proving they are using “secure software development.” They’re also strongly suggesting all companies, regardless of their government affiliations, do the same thing.

This kind of ask will become even more common in the future. Why? Because secure software development hardens a company’s infrastructure against hackers. With NIST-compliant documentation, you’ll prove you’re running a full battery of security tests and acing the results.

In an era when strong IT security can be a selling point, clients, vendors, and cyber risk insurers are “asking for the receipts.” Why wouldn’t you want to provide them?

Still, any directive from the government can be a cause for anxiety, especially ones that require reams of paperwork. Let’s explain exactly what the government is asking for and how that affects you. I’ll start with a narrow definition of secure software development.

What Is Secure Software Development?


Secure software development is a process for ensuring the software you’re using plays well with your systems. It really is that simple.

Whether the software you use is internally produced or purchased as part of a cloud-managed SaaS package, you can use the secure software development process to continuously check for missing patches, vulnerabilities, and compatibility problems. Find them fast, and you’ll close those security gaps hackers love to wiggle through. Then, it’s just a matter of keeping track of that mitigation.

When Do You Need Secure Software Documentation?


The short answer is all the time. We recommend that you create a process to automatically manage and document new patches, vulnerabilities, and incompatibilities in all your systems. The best documentation systems start with a continuous scanning program with a dashboard allowing you to see all your alerts and remediations in real-time, then generate a report.

But your documentation should start well before that—in the design stage. If you are developing your software, that code must be stress tested in your system at every stage of its development. When you load up a new bit of software, there should be no surprises.

Creating the documentation you need is not a quick, straightforward affair. However, qualified cybersecurity professionals working in your organization or at your MSP should have the expertise to generate the tests, reports, and policies you need to keep your organization covered.

What do those documentation protocols look like? The National Institutes of Standards and Technology (NIST) has provided this overview to get you started.

Most companies know they must provide a certain amount of software documentation. Yet, too many companies aren’t creating documentation that’s up to these new NIST standards. Let’s talk about some of the significant deficits we commonly see when clients begin this process.

Opportunities for Secure Software Documentation Many Companies Miss


Getting your software documentation in order is not a simple matter of printing a report out often. It’s a philosophy—one where you’re checking everything all the time. Then, you’re warehousing documentation of those remediations in a way your whole IT organization can access.

When we take on a new cybersecurity client here at Integris, we conduct a thorough assessment and security review. Some of the most significant deficits we see involve secure software documentation. Here are the most common offenders:

Failures in Threat Modeling


Before a piece of software or new code is added to your system, you should deconstruct it. Then you should check its compatibility with your other systems and identify the threat vectors that could create problems. The Open Web Application Security Project (OWASP) has a detailed threat modeling process that I’ve often found helpful in understanding the steps involved in threat modeling. Companies often miss some or all of these steps, throwing a wrench into their documentation process.

Failure to Create Solid Documentation Policies


Companies need to write their documentation process into their IT policies. It’s key to setting expectations in your organization and keeping communication strong. But more importantly, regulators and cybersecurity insurers will want to know that you have policies established for your organization and proof that you are following them. NIST outlines expectations here, but for access to free policy templates, try these from the SANS Institute.

Failures in Logging


I’ve mentioned that companies should have their software scanned at the code level continuously. But what happens in the logging of those scans is just as important. Companies often don’t log enough, or as comprehensively, as they should. When you’re evaluating a software application, at minimum, logging should be done for:

  • Repository logging for code changes, build releases, and versioning for source control
  • Logging for security scanning of the application’s actual code, the live website, manual penetration testing, and vulnerability reports for third-party components
  • Review logging every time new components are added or changed

Failure to Check SaaS Agreements


With advances in cloud software, it’s easy to believe that you can plug and play with these web applications, and you’ll be fine. After all, wouldn’t a significant provider like Microsoft be on top of their logging and patching? Yes, of course, they are. But every time that web application touches your system, you’re putting yourself at risk.

That’s why the SaaS providers you use must provide you with detailed documentation of their security efforts. You must also log all the remediations and testing of those changes on your end.

Assuming Every MSP Can Handle Your Documentation Load


Not every MSP is equipped to cover all your documentation requirements. We aim to provide that level of comprehensive service at Integris, but not every MSP is prepared for this. Please read the fine print on your contracts with your MSP and ask them how they plan on handling documentation and continuous security scans. If their services don’t cover this, at least hire internal staff or IT contractors that can fill this gap for you.

Giving Internally Developed Software a Pass


Your team may have custom-coded software for your systems, but that doesn’t mean they get a pass on testing or documentation. We often find problems in internal code when it’s suddenly interfacing with new SaaS services or strung out over more endpoints. A good rule of thumb is to have an independent developer checking your internal software as it’s being coded and continuously as part of your whole system scans once it’s live.

Getting Lax with Patching


Does your company have a process in place for dealing with software patches? How quickly do you turn around remediations when receiving a vulnerability report and patch for your software? If the answer’s not immediately, you’re putting your company at risk. If you don’t have the internal resources to handle the constant stream of patching updates, it may be time to hand that over to a good MSP.

Doing Annual Reviews


Are you caught up in the day to grind of doing continuous updates and patches? It’s not enough to keep up. You should review and update your documentation at least once a year, if not once a quarter. A thorough review by a vCISO or other security experts can help you determine what documentation you’re missing and where to step up your security systems to meet current government recommendations and regulatory burdens. With this kind of review, you can treat your documentation like a blueprint and a roadmap for your security services, helping you take a top-down, macro look at your efforts.

It’s Time to Step Up Your Secure Software Development


Threats to your company are stretching across industries and borders. The new guidance from the government raises the bar for security for all companies. It’s an excellent start for a conversation with an MSP, or your internal department, to ensure your documentation can meet these new standards.

Need help? Contact us for a free consultation! Our vCISO organization at Integris can give you the high-level advice you need.

Lexie Nelson is a vCISO at Integris and a Certified Information Systems Security Professional (CISSP).

Keep reading

Signs an Email is Phishing: 5 Signs of Phishing in Your Inbox

Signs an Email is Phishing: 5 Signs of Phishing in Your Inbox

For years we've read articles teaching us to identify the signs an email is phishing. We all know the signs, yet we still miss the blatant indicators and take the bait. According to Security Magazine, citing SlashNext, "The first six months of 2022 saw more than 255...

A Personal Twist on Zero Trust Security

A Personal Twist on Zero Trust Security

The massive Australian data breach in late September inspires me to share a personal twist on Zero Trust Security. What makes this incident colossal? BBC News Australia reports, "Australian telecommunications giant Optus revealed about 10 million customers - about 40%...

How Much Do Managed IT Services Cost? (Factors & Price Ranges)

How Much Do Managed IT Services Cost? (Factors & Price Ranges)

Several factors drive the cost and price ranges of managed IT services. Fees range between $100.00 to $250.00 per user per month. Factors that affect cost are headcount, the size and sophistication of your IT systems, and whether you outsource some or all of the...