THANK YOU FOR SUBSCRIBING
Enterprise Networking Mag Weekly Brief
Be first to read the latest tech news, Industry Leader's Insights, and CIO interviews of medium and large enterprises exclusively from Enterprise Networking Mag
Lee Bailey, Director, Information Security & Compliance, Tupperware BrandsCoachJohn Wooden (University of California - Los Angeles) started each basketball season with the same, fundamental lesson: teaching each player how to put on their socks and tie their shoelaces. The ‘why’ behind the seemingly redundant lesson: "…if there are wrinkles in your socks or your shoes aren't tied properly, you will develop blisters. With blisters, you'll miss practice. If you miss practice, you don't play. And if you don't play, we cannot win." In other words, remember the fundamentals.
A question: what are application security fundamentals and how does a technology leader explain them to a project manager or a developer? Two great questions. In order to answer these questions we will make two assumptions for the remainder of the article. The first assumption is our organization is just starting to develop structure around application security. The second assumption is there are limited people, technology, and financial resources to implement the maturing application security.
The fundamentals of application security, which we can explain to any project manager or developer, are:
a. Remember Plan – Do – Check – Act.
b. Engage all stakeholders early.
c. Understand then address risks associated with the application and the data.
d. Re-use approved technology blueprints or processes whenever possible.
Notice these application security fundamentals are not technical controls or detailed processes focused on software development. Instead, they are people and process driven which all team members understand. They are also not a single checklist a developer can apply to every application. These application security fundamentals are leadership focused with the goals of (1) aligning the development & project management teams with the information security & privacy teams, (2) raising security and privacy awareness, and (3) providing opportunities to standardize and improve SSDLC processes for future development projects.
In practice and in the spirit of Coach Wooden, “…if the team doesn’t follow these fundamentals then there will be organizational friction (i.e. tension, blame or “blisters”). If there is organizational friction then the project will slow down and escalation will occur. If the project slows down and escalations occur then everyone will be distracted, which may cause missed deadlines OR longer work hours to make up the time. It may also cause the team to push through a solution that does not address the risks or require leadership to accept risk the team could address.
“If there is organizational friction then the project will slow down and escalation will occur. If the project slows down and escalations occur then everyone will be distracted, which may cause missed deadlines OR longer work hours to make up the time”
These are the application security fundamentals from a leadership perspective. The expectation is the SSDLC will mature and the team will add technical controls with detailed processes. The following checklist is a reference for organizations building out Secure Application Development capabilities.
Focus Area 1: Organizational Risk Management
Question: What company level risks must the application address?
- Potential Stakeholders: CIO, Organizational Risk, Internal Legal
- Considerations:
o Third Party Risk (ex. NDA, MSA, DPA, SLA, IR Notifications)
o Compliance (ex. PCI, Privacy, Sarbanes Oxley)
o Handling of Company Proprietary Information
o Impacts to Insurance (ex. Cyber, Intellectual Property)
o Incident Response Planning
Focus Area 2: Governance – Policy, Standards, Guidelines
Question: What company level governance must the application address?
- Potential Stakeholders: CIO, Organizational Risk, Internal Legal, CPO,CFO, CTO, CDO, CISO, Marketing, Human Resources, PMO, Internal Audit
- Considerations:
o Technology – Does the company have approved platforms (ex. cloud, datacenters)?
o Software Development – Does the company have approved languages or development methodologies?
o Project Management – Does the company require formal oversight?
o Security – What security standards and guidelines apply?
o Privacy – What privacy standards and guidelines apply?
o Department Specific – What department specific requirements apply (ex. GAAP)?
Focus Area 3: Infrastructure and Cloud Security
- Potential Stakeholders: CIO, CISO, CTO, CDO
- Considerations:
o Asset Management – Where do the systems reside and where is the data stored, processed or transmitted?
o Network Security – What protections are available at the network layer (ex. WAF, VPN)?
o Endpoint Security – What protections are available on the endpoint (ex. white listing)?
o Identity & Access Management – How can we ensure least privilege, segregation of duties and segmentation of environments/data?
o Logging and Monitoring – How will the system detect & alert on poor performance or suspicious activity?
o E-discovery/Data Loss Prevention (DLP) – How will we detect, alert, and/or block unauthorized data creation, access or movement?
o Vulnerability Management – How are vulnerabilities detected and remediated prior to production and thereafter?
o Privacy Management – How will the solution handle Data Subject Access Requests (DSARs) and data retention?
Focus Area 4: Secure Software Development
- Potential Stakeholders: CIO, CISO, CDO
- Considerations:
o Secure Coding Awareness & Training
o Software Composition Analysis
o Secure Code Reviews
o Application Security Testing (see Vulnerability Management)
Read Also
