| | Discussion with Tim Bradish, Cornell Univ | | - Ass't Director of security operations. Also joined by Dan Villanti.
- Office offers security assessment service: does the vendor meet all of the security requirements and did the Cornell customer implement in the software so as not to degrade security. Helps clients assess and manage risk of implementing systems.
- Office is tying into the procurement office process.
- Questions asked: What is the functionality of the product? What is the data that is in play? (data: confidential data, restricted data, public data; users: just Cornell, in conjunction with others, public access)
- How is data handled (masking, obfuscation)? Encrypted at rest and/or in transit? Logging around data acquisition and access.
- Focus on integration with other systems. How implementations are designed from a risk point of view (e.g. a poorly designed integration with SalesForce using OAUTH tokens that were shared). Look at data types exchanged, authentication/authorization options (e.g. embedded passwords in the code are frowned upon), mechanisms (push/pull files, standard/ad-hoc APIs).
- Enforce HTTPS only; ensure certificate management practices (revocation processes for exposed keys, renewal processes)
- Software development: a formal software development lifecycle; building in security as the software is developed; document that the is a formal process for regression testing, penetration testing, code review, change management. Following checklists such as the OAUTH top-10 list, cross-site request forgery, etc.
- Policy decisions: retention requirements for data? Legal requirements/obligations
- Infrastructure security: a joint effort, especially in cloud arrangements.
- Incident response plan documented? Who's role to do this?
- Disaster recovery, business continuity.
- Privacy policies, consent from the user, how that consent is granted.
- Data minimization.
- Re-evaluation as use of the application changes (e.g. does it start to contain HIPPA-covered data?).
- Offered to help with specific questions from a security perspective.
- With open source systems, it is the third-party modules that most often have the security problems in the system. Encouraging documenting how to write code in a secure manner, communication with developers on how good code is written. Have someone other than the author perform a code review if possible.
- Think about in the design process: how to make it flexible and transitionable as time and technologies change.
- Building a logging framework into the core of the application; have the ability to turn modules on-and-off. Some applications send out so much information that makes it unusable (debugging versus audit logging).
|