Share what you know with millions of people
Focus is the best place to turn what you know into remarkable content
0
How does security tie in to the software development life cycle (SDLC)?
Events
- Dos and Don'ts of Small Business Marketing May 29 @ 11 am PT
- Lead Nurturing 202: The Next Generation May 31 @ 11 am PT
- The Tricks to Paid Media June 6 @ 11 am PT
- Display Advertising for Brand Awareness June 20 @ 11 am PT
Related Activity
5 Answers
Ideally, security testing and evaluation should be integrated at several points in the SDLC.
First during the design phase application designs and workflows should be reviewed by security personnel to make sure planned transactions and operations don't have inherent security flaws. This time, before code is written or compiled is the best (and least expensive) time to discuss things like applicable compliance and data security concerns. Too often, this opportunity is missed and additional work is required later to secure transactions and communications that could have been better designed.
Next at unit testing, code reviews and security scans should be performed as part of normal application code testing. This again is an opportunity to catch flaws and issues early while the product is still in development before work-arounds are required.
Finally at UAT when the various components are joined together and tested as a whole, full vulnerability scans should be performed and the security team should be on the list of application approvers.
Unfortunately, these opportunities are often missed and an application gets only cursory review by security teams after it’s already slated to go into production if at all. Typically the infrastructure and network security take precedent over application-specific security unless there are compliance requirements (like PCI or HIPAA) or the application will be public-facing.
Hi.
First stage, known as phase 0, is the one where all stakeholders become "security-aware". That is, they need to live, breath security, to fully understand it. Security is not a software thing, but a system thing, where system includes elements like hardware, software, humans and institutions.
When everybody understand the security is not in code but a way of living, we can start deciding what we need business wise. That is, we start with requirements gathering. That phase must include non-functional requirements, also known as quality properties, which may be related to performance, security, reliability, etc. That is, security requirements should be as important as the functional ones. Here a risk analysis should be done. Threat modeling, risk control methodologies, definition of minimum residual risk, etc should be defined.
Then comes design. The actual decision at architectural and tactical levels should take into account all identified threats, and new reviews should be performed so any design decision may not introduce new threats.
At coding, there is enough documentation of what to do, what not to do, what hackers do and how can your try to dissuade him to do it.
Of course, testing phase (which should be blended with coding and design, as test is also designed and coded), should help evaluate that risk goal is met.
Then, deployment and acceptance of the solution, with validations and certifications.
Finally, one phase that is often forgotten is disposal. Systems come to die with time. And when we stop the last process, there are many procedures that should be executed to sanitize, destroy or seal data that must be protected, plus other security related tasks.
Yes, security is all over the place, all the time.
Nice softball Brielle! There are many great resources on the How, my fav http://www.microsoft.com/security/sdl/default.aspx
The key question is Why?
What are the benefits of SDL and why is it important for your organization. Reputation, cost of remediation late/after the cycle, incidents. Since SDL incurs additional cost, top down support is mandatory. You probably don't have to go crazy on quantifying the cost of security bugs e.g. https://buildsecurityin.us-cert.gov/bsi/articles/knowledge/business/267-BSI.html , but at least one smoking gun really helps.
The best bet is to align the benefits of SDL to the objectives of the organization. After you pilot with a supportive team, metrics are a great way to show progress e.g. post-prod security bugs vs. a non-SDL project.
Another great technique is to evolve the SDL as support widens e.g. start with a central service of expert pgm's, testers, devs acting as consultants who then train team by team. Eventually you can disband the Center and measure across teams. A good starter metric is % of projects with SDL. Advertising SDL adoption is a great way to build support.
Good stuff.
Information Security *should* tie into the SDLC, because security is always more effective as an ingrained process, rather than one that is added after the fact.
However, I would be surprised if a high percentage of organizations that employ a software development life cycle even do more than pay lip service to security, outside of basic things like user accounts and passwords.
If you're not thinking about how your application can be used, and what elements have security implications, then you are making it simpler for attackers, who most certainly think about these sorts of things.
Think that various Adobe products couldn't have benefited from security being a more intrinsic part of the application? I bet they could....
A thorough risk analysis should occur early in the SDLC, prompting inclusion of mitigations in technology, physical site preparation, installation procedures, operating procedures, administrative procedures, user training, and user documentation.
Authoritative references, e.g., NIST SP800-53, should be used to help assure adequate mitigation strategies are included.
Later in the SDLC a reassesment of risk should occur, to account for new facts as they become known.
Vulnerability testing should be part of unit and integrated testing, site readiness review, and installation verification. Ongoing periodic and random vulnerability testing should be part of the administrative and operating procedures.
Answer This Question