Products + All Products + Software Integrity + Semiconductor IP + Verification + Design + Silicon Engineering
Posted by Jamie Boote on October 19, 2015
The bad news is that software gets hacked. The defects or vulnerabilities that attackers take advantage of to hack software can be made by an organization internally, or by their vendors or partners. The good news is that remediation methods to resolve these defects and vulnerabilities are well known. Organizations with a mature software security initiative (SSI) have processes and guidance in place that go beyond a basic “penetrate and patch” approach. These processes will set up a prevention approach that stops some defects from ever being created and ensures other defects are fixed during development rather than right before, or even after, release. So, how proactive is your software security initiative?
The below questions are inspired by the Building Security In Maturity Model (BSIMM) and highlight activities commonly observed in real software security initiatives. They weren’t thought up in a classroom or around a conference table, but were observed being performed by real companies who consider security a worthwhile investment.
Learn more about the BSIMM and how to use it to measure your software security initiative.
It all starts with knowing. While organizations with an advanced training program provide on-demand training based on an employee’s role within the organization, most organizations offer some software security training.
59 out of the 78 BSIMM6 participants provide basic software security awareness training.
In order to finish the race, you have to know where the finish line is. In order to achieve security, standards have to set the goals for organizations and their engineering teams.
57 of the 78 BSIMM6 participants create or adapt their own software security standards.
Security features are tools and the hammer that pounds the nail can easily crush your thumb. Development teams and security-aware architects should ensure that the security features they use can’t be easily bypassed by attackers.
67 of the 78 BSIMM6 participants perform reviews to see how their security features might fail or be implemented incorrectly.
Good external penetration testers will approach your application the same way hackers do. By bringing in third-party experts, you are bringing both new expertise and an unbiased eye to your testing efforts.
69 of the 78 BSIMM6 participants use external penetration testers to some degree.
Bugs crawl around the source code. A great way to kill them is with a review. Automated tools ensure a consistent level of security expertise that supplements manual code review effort.
55 of the 78 BSIMM6 participants use an automated code review tool along with an established set of rules.
Software that functions insecurely isn’t software that functions well. The designers of an application will know the potential weak points of the software and should direct testers to evaluate the security of those areas, particularly the design and implementation of security features.
66 of the 78 BSIMM6 participants create test cases to evaluate security features and security requirements.
When everything is a priority, nothing is a priority. Organizations will have a limited budget and one way of allocating those limited dollars can be by ranking applications according to the data they handle.
51 of the 78 BSIMM6 participants have a data classification scheme and prioritize applications within their inventory according to the scheme.
Some problems are best solved only once. After a while, teams and organizations will start solving standard problems with standard solutions, whether internally-built or integrated COTS.
61 of the 78 BSIMM6 participants have pre-approved solutions available for developers.
Privacy is a hot topic. The decision to collect, or not collect, personally identifiable information (PII) data can be a big one and by accepting certain pieces of information, your organization may be opening itself up to additional risk.
61 of the 78 BSIMM6 participants identify PII obligations and define best practices surrounding PII.
While a secure network and host aren’t a complete security solution, insecure infrastructure and servers can let hackers access your application in ways never intended. Ensure that servers, networks, and other infrastructure follow approved environment and configuration guidelines for additional depth of defense.
69 of the 78 BSIMM6 participants analyze the server and network configurations to prevent vulnerabilities at those levels.
Nobody is perfect. Having a good communication flow between developers and operations is a great way to close the loop on the bugs that make it past all the safeguards.
73 of the 78 BSIMM6 participants have open channels of communication for relaying security defects back to the developers and improving processes.
When developers know when the test will be, they can be better prepared. Organizations should perform tests at regular stages of development to ensure that software is being developed securely.
66 of the 78 BSIMM6 participants set security gates and check security-related artifacts during the SDLC.
It takes a village to raise a child and it takes an entire organization to ensure success with an emergent property such as security. Small changes and safeguards can improve security at every step of the way. While not every activity is right for every organization, if you aren’t doing at least a few of these activities, your organization is subjecting itself to easily addressable risk from the unknown.
About the Author
Jamie Boote is a Security Consultant with Synopsys. He works with organizations to ensure their developers understand how to write secure code. Jamie believes that software security doesn’t happen in isolation and needs effective communication between all levels of a company. When he’s not advocating for the dinosaurs in any Perl vs. Python argument, Jamie can be found chasing his sons around Southern Florida.