publication of the International Legal Technology Association
Issue link: https://epubs.iltanet.org/i/192213
FIVE STEPS TO BUILT-IN XXXX SOFTWARE SECURITY and guaranteeing uptimes and privacy clauses in legal addenda to existing contracts. What security documentation is needed? Security is a very visible element of every operating THE PENETRATION TESTING MYTH Perhaps the most prevalent security misconception today is that an organization that does penetration testing on their software products is an organization that builds secure products and has a secure software process in place. Security testing is considered equivalent to penetration testing. Nothing could be further from the truth. Organizations that rely only on penetration testing as a method for developing secure software will run into multiple problems. Since penetration testing is done at the end of the development cycle and no other security analysis is in place at that time, chances are the penetration tests will find many security flaws or defects that need to be fixed. The time and effort to fix these late-breaking security defects result in delays to the release cycle, added risks of changes to the code late in the development cycle and putting the project schedule at risk. environment. It is likely that as the product begins to go to market there will be customer questions for marketing and product teams on the security of the product or system. Every new product should have these major categories of security documentation as part of the project deliverables: •Security Architecture: For review by customer security teams application or system and decides which parts of the STRIDE threats exist for the component. The security architect will also map the data flows and create a data classification matrix that indicates which parts of the system might require a higher security design consideration. For example, if some parts of the system are processing credit card information, it will be critical that those processing components comply with applicable regulations (e.g., PCI-level regulations for confidentiality of data in transit). •FAQ: For general distribution to those on the front line with customers and serving as a security positioning statement for the internal marketing team This is also the stage where security algorithms to be used are reviewed and finalized. •Security Overview: For initial RFP presentations and reviews Security testing in the development cycle falls into two categories: SECURITY TESTING •Security testing through structured security tests •Results of Penetration Tests andPENETRATION TEST Security STATIC ANALYSIS Scans: For internal use and reference • All applications every • Mobile applications •Security testing through the standard quality sixth months • New platform assurance process development At the design stage, a threat-modeling and business impact analysis needs to be conducted for the Structured Security Testing: Security testing security issues expected. A common approach is though structured security tests involves testing to use a STRIDE (spoofing, tampering, repudiation, through static code analysis as well as penetration information disclosure, denial of service, elevation testing. Regular analysis of the static code is critical of privilege) model to map the threats into various to ensure that secure code is being developed right from the beginning of the project. I recommend categories and severities. The security architect beginning the static analysis at the end of the first usually looks at the individual components of the PRODUCT DESIGN