Organizations want assurance that the software products they acquire and develop are free of known types of security flaws, and the cyber environment of a user or organization is protected.
At the same time, organizations usually don't have a plan, vision on how to kick-off, and build the security audit process for their software systems. We would like to pin-point things to start with we think are essential as of experience we have in Plexteq.
Set up the goal
The principal objective is to reduce the risks, including the prevention or mitigation of cyber-attacks.
While the cyber environment may comprise different components, such as networks, devices, all software, processes, the information in storage or transit, applications, services, and systems that can be connected directly or indirectly to networks. In this post, we mostly focus on custom-built software.
Get familiar with methodologies
We recommend getting familiar with Cyber Threat Susceptibility Assessment (TSA), which is a methodology for evaluating the susceptibility of a system to cyber-attack developed by MITRE. TSA quantitatively assesses a system's [in]ability to resist cyber-attack over a range of cataloged attack Tactics, Techniques, and Procedures (TTPs).
This methodology tells us about a great tool and a database called Common Weakness Enumeration (CWE), a category system for software weakness and vulnerability, is now in use to provide a common vocabulary for source-code analysis tools for those developing mission-critical systems.
CWE is based on work that MITRE began in 1999 called the Common Vulnerabilities and Exposures (CVE). The CVE list was a preliminary classification and categorization of vulnerabilities, attacks, faults, and other concepts to help define common software weaknesses.
It’s unfortunate that few developers are familiar with The MITRE's Common Weakness Enumeration list of common software problems. The CWE is a fascinating and valuable resource, not just to the software security community, but to the broader development community.
Reading through the CWE, it is disappointing to see how many common problems in software, issues that lead to serious security vulnerabilities and other serious problems, are caused by sloppy coding: not missing the requirements, not getting the design wrong, or messing up an interface, but simple, fundamental errors. The CWE is full of mistakes like null pointers, buffer overflows, missing initialization, resource leaks, string handling mistakes, bad error handling, leaving debugging code enabled, and language-specific and framework-specific errors and bad practices – not understanding, improperly using the frameworks and APIs.
Top 25 Most Dangerous Software Weaknesses as of 2020 by MITRE shown below just proves nothing changes over the years. Developers are making almost the same mistakes and don't spend enough time to educate themselves well enough regarding the security fundamentals.
Get the basics done right
CWE is not only a list of common weaknesses. It's a powerful way to learn to understand what are the different types of weaknesses that can be exploited by the attackers to intrude and exploit the IT stack of any organization. See how well and structured one of the most common weaknesses are described with reasons, examples, and instructions to avoid that:
Hence here we may name the next point – require discipline when it comes to security and reliability:
Hire good developers and give them enough time to do a good job, including the time to review and refactor.
Make sure the development team has training on CWE the basics, that they understand the language and frameworks.
Regular code reviews (or pair programming, if you’re into it) for correctness and safety.
Use code static analysis tools to find common coding mistakes and bug patterns.
Build up a repeatable process
To be successful in something, you need to make that process repeatable and build up a system. Here we recommend checking into existing security industry regulations and standards, at least the following:
Federal Information Security Management Act (FISMA)
Payment Card Industry Data Security Standard (PCI-DSS)
FIPS 199 & 200 (Federal Information Processing Standard Publication 199 & 200)
NIST Special Publication 800-53
Specifically, we would recommend checking into FISMA and its maturity levels. FISMA defines a framework for managing information security that must be followed for all information systems used or operated by a U.S. federal government agency. This framework is further defined by the standards and guidelines developed by NIST.
FISMA maturity levels are similar to CMMI levels, which allow evaluating the organization's maturity in managing information security. We recommend targeting Level 3 in the midterm.
We believe that any organization should grow and learn from ad-hoc to at least a "consistently implemented" level which means achieving consistency in applying security-related policies and procedures to the developed software codebase. This level is the minimum baseline requirement to achieve the initial goal.
We bet you'll spot and adopt a lot of other essential points needed for your product from the mentioned regulations and standards.
Conclusion
Secure software, like reliable software, doesn’t come for free, especially up front. It would help if you changed the team’s way of thinking: to use risk management to drive priorities, add more automation for proactive threat identification. Learn from industry standards, specifications, and reports. Get your best people to understand and commit: the rest will follow.
header.all-comments