The military has a vested interest in keeping information secure — and their strategies are worth adopting for private cybersecurity. OPSEC (Operations Security) is an in-depth security and risk management strategy that assesses potential threats and risk to sensitive data and outlines what countermeasures are needed to protect that data and prevent it from getting into the wrong hands.
Though the internet’s rise to omnipresence brought about innovation and prosperity, it also became a vehicle for malicious attacks on our nation’s networks, infrastructures, and our most vulnerable populations. In today’s cyber threat landscape, no target is too small — or too big.
The Colonial Pipeline ransomware attack in 2021 made apparent the potential impact of just one cyberattack. President Biden signed Executive Order (EO) 14028 to bolster national cybersecurity standards in response to this incident — and the steep rise in cyberattacks preceding it.
Let’s face it: pinning down the perfect set of defensive standards is impossible. Malicious actors will constantly evolve and change tactics to evade our cyberdefenses. But EO 14028 gets a lot of things right when it comes to cybersecurity on a federal level. Let’s look at four ways it does this well.
Rather than leave federal systems open to malicious attacks, agencies are now required to operate on secure cloud services with zero-trust architecture. These requirements allow agencies to function with all the convenience and efficiency allotted by cloud services but with minimized human error that allows threat actors to breach them.
Users can only gain access to federal information through multifactor authentication (MFA), which adds several layers of protection to every set of credentials. Cybercriminals would not only need to infiltrate the correct devices, but infiltrate them at just the right time to fake their way into a federal system.
It’s become clear that, while every federal network is interconnected with dependencies (think communities, industries, and critical infrastructure and processes), its safeguards have not necessarily kept up with modern threats. This level of connectivity called for a serious re-examination of foundational cybersecurity standards for all federal agencies.
EO 14028 institutes higher security standards for the software every federal agency uses. Multiple agencies — including the National Institute of Standards and Technology (NIST) — now oversee initiatives to make computing environments safer. In accordance with EO 14028, NIST:
Provided guidance to safeguard software supply chains.
Published minimum standards for software development.
Established security measures for critical software.
Incident response standards also received a much-needed upgrade. Federal departments and agencies now have standard playbooks for federal system breaches — which the Cybersecurity and Infrastructure Security Agency (CISA) has made publicly available for any organization to learn from. The playbooks cover everything, including:
What to do during a breach.
How to contain a threat.
The follow-up steps required post-incident.
Information around a cyberattack can leave a trail of digital crumbs leading to its source and (if we’re lucky) solutions. So the more we can gather as close to that source as possible, the better. That’s where the Federal Acquisition Regulation (FAR) and its closely linked supplement, the Defense Federal Acquisition Regulations Supplement (DFARS), come into play. Executive agencies like the DoD and NASA use FAR and DFARS to acquire supplies and services, including software.
EO 14028 calls for updates to FAR’s and DFARS’s language, requiring vendors to report incidents and share detailed and timely information about cyberattacks. Information on who was attacked, when, and how can be shared with fellow industry professionals and experts to build a solid, united front against threat actors.
Adding to that united front, removing barriers to information sharing allows for more effective communication from many perspectives. So it’s to everyone’s advantage that EO 14028 encourages not only collaboration between federal agencies, but also federal agencies and organizations in the private sector. The Cybersecurity Safety Review Board, comprised of leaders from both worlds, was established under the executive order.
The board convenes after significant cyber incidents to share information, analyze what happened, and recommend ways to prevent or mitigate future attacks. In light of the attack on the Colonial Pipeline, their first meeting focused on remediating its cascade of industrial damage and addressing the vulnerabilities threat actors exploited — particularly in the log4j library.
While EO 14028 isn’t an instant fix, it lays solid groundwork for a higher standard of cybersecurity fundamentals at the federal level. Its primary directives leave room for — and even encourage — growth and flexibility in facing down cyber threats. Consistently improving proactive measures, keeping detailed records, and pushing for collaboration will help us, as a country, build upward from there.
Cybersecurity is “one of the most serious economic and national security challenges we face as a nation.”
That’s not the team here at CodeHunter trying to scare you. Those are the words of the Executive Branch over a decade ago.
The cyberscape has changed drastically since then. Multiple presidential administrations have recognized how serious the national cybersecurity situation is. In 2017, the Trump administration passed Executive Order 30018 to modernize federal IT infrastructure, better secure critical infrastructure, and collaborate with allies. And in March 2022, President Biden issued a statement recognizing the dangers international cyber warfare posed to the U.S.
So while cybersecurity might seem like an abstract concept to many citizens, we at CodeHunter know that implementing stronger cybersecurity measures is a national priority.
CodeHunter’s concern for our nation’s cybersecurity stems from our combined experience in the federal cybersecurity sphere.
Chris O’Ferrell, CodeHunter’s CTO, is a U.S. Army veteran with over 30 years of cybersecurity experience. During his time in the industry, he has worked for a variety of agencies — on bureaus, black projects, counterintelligence, intelligence work, counterterrorism — all related to cybersecurity.
Based on his experiences working with the U.S. government, he has always stressed that solving cybersecurity problems will not only save networks, but will ultimately save lives.
As our nation faces constant attacks on critical infrastructure and public institutions, CodeHunter understands those federal agencies need a proactive solution based on a zero-trust framework to keep up.
Protecting federal systems is more than preventing cyberattacks and hacking. It’s a matter of preserving national security. Learn how CodeHunter can help federal agencies protect our nation and its citizens.
With the cyber threat landscape as dangerous as it is, development shops need all the guidance they can get to build secure software. Fortunately, the National Institute of Standards and Technology (NIST) created the Secure Software Development Framework (SSDF) in response to Executive Order 14028 and the infamous cyberattack on the Colonial Pipeline.
Here’s how you can leverage this framework to write robust software development contracts and ensure developers are following best practices.
SSDF is a set of cybersecurity guidelines intended to reduce the number of vulnerabilities in software used by federal agencies. But it can apply to any organization, and it’s worth building into your software development contracts.
Software developers in any sector can (and should) compare their own practices to the SSDF to find weaknesses and liabilities when developing software. NIST defines four best-practice categories in their approach to standardizing federal cybersecurity to give agencies an idea of what a well-secured network looks like.
Prepare the Organization (PO): Ensure that your organization is prepared to develop software securely.
Protect the Software (PS): Protect all components of your software from potential threats.
Produce Well-Secured Software (PW): Produce secure software with minimal vulnerabilities upon release.
Respond to Vulnerabilities (RV): Identify and address any residual vulnerabilities in released software, and work to prevent future vulnerabilities.
Understanding NIST’s fundamental categories for sound and secure software will help identify which requirements to build into development contracts. Consider leveraging some or all of the following ten steps into contracts to strengthen your cybersecurity efforts.
Define criteria for software security checks.
Protect all forms of code from unauthorized access and tampering by safeguarding the development, build, distribution, and update environments and following the principle of least privilege.
Provide a mechanism for verifying software release integrity by digitally signing the code throughout the software lifecycle.
Verify that third-party software complies with security requirements.
Configure the compilation and build processes to improve executable security.
Test executable code to identify vulnerabilities and verify compliance with security requirements.
Review and/or analyze human-readable code to identify vulnerabilities and verify compliance with security requirements.
Configure the software to have secure settings by default.
Archive and protect each software release.
Identify, analyze, and remediate vulnerabilities continuously.
While the SSDF provides a great foundational framework for secure software development, there are considerations to take into account regarding which practices can realistically be implemented. Time and resources are precious commodities in software development. It helps to consider your most limited commodity and prioritize around that to minimize risk — of either a failed software delivery or a successful cyberattack.
While planning for software development, with all its processes and milestones mapped out, consider what might be put at risk with certain requirements. Can dates be met the number of rigorous security and QA checks needed? What about the financial risk if a process takes longer or needs more resources than expected?
With regard to financial risk, there may effectively be budgetary limits on which requirements can be implemented. If this is the case, prioritize the ones that will keep the network most secure from threat actors.
Is there access to the right resources to address the requirements and make the security checks planned for the contract? Are the requirements excessively cautious or overly restrictive? Are you asking too much? It might be worth consulting with a developer before submitting your contract if you’re unsure.
Are the requirements really applicable for the end product? Are they going to help in its development or just cost more time and resources?
Planning for growth is important for any organization. Consider which requirements are scalable. Automating some of them may also help keep costs down in the long run.
Consider cybersecurity practices in place: make sure new requirements won’t disrupt valuable existing processes.
Even for those not developing software themselves, it pays to stay up to date on the latest fundamental cybersecurity measures. To further stretch and test your knowledge, try hosting cyber wargames within your organization or learn more about malware and shadow IT.
