Security, Privacy

and Compliance

Training 2020

Olivier Le Rudulier
PM Director Cybersecurity
Confidential
 Agenda

A Security Program Overview

B Secure Development Activities

C Detailed Practices

D Self-Directed Linked Education

2 quest.com | confidential
Business drivers
Business drivers
• The threat landscape is significantly changing
– Massive data breaches lead to identity theft, followed by lawsuits followed by regulations
– State-based cyber-attacks on the rise, real concerns about external interference

• Customers
– Federal requirements (NIST, FIPS, FedRAMP, STIG). Quest is fixing its image issue from
2017.
– Private sector verticals (ISO, SOC 2, CSA, end-less request of Security questionnaires)
– SaaS portfolio, additional demand for on-premises product (Third-Party assessments)

• Legal obligations:
– Governance and due diligence obligations at ELT level
– Privacy: GDPR, CCPA

Need for Quest to enhance its Information Security Management System. R&D has a big play in it.
4 quest.com | confidential
Security Program
 Program goals
• Educate and grow a Security Culture as security is everyone’s job
• Structure the Policies and Processes through which Security, Privacy
and Compliance of the Platform Management portfolio is achieved
• Ensure alignment with strategic Quest Information Security goals
• Set some realistic roadmap to enhance our Security Maturity

Level 1 - Initial Level 2 - Repeatable Level 3 - Defined Level 4 - Managed Level 5 - Optimizing
Capable Efficient

Experience
Good all days ;-) 2016 Most on-prem Most SaaS Metrics 2021/22 some day, may be…
products products Tools

6 quest.com | confidential
Pilar 1: Software Development Lifecycle (SDL)
Based on The Microsoft Security Development Lifecycle (MS SDL) - ISO 27034-1 compliant

Details on Wiki: https://wiki.labs.quest.com/display/MPM/Security+Development+Lifecycle

7 quest.com | confidential
Pilar 2 R&D Best Practices

Details on Wiki: R&D Best Practices

8 quest.com | confidential
 Security Control Description
Security Training 3.5 hours of assigned Security Training required for developers, managers and directors.

Secure Development Lifecycle Follows and internally audits secure development lifecycle the best practices.

Bundled 3rd party software is checked for vulnerabilities via standard process before application
Third Party Software release.

Vulnerability Scanning All software is scanned for vulnerabilities by utilizing an industry standard SAST/DAST product.

Penetration Testing SaaS products undergo third party penetration testing annually.

All products are scanned for malware before release with two independent industry standard
Malware Scanning anti-malware scanners.

Code Signing All Software distributed to customers is cryptographically signed using Quest’s official signing key
which validates authenticity.
Checksums for software installers are published for customers to ensure integrity of distributed
Software Integrity software.

Insider Threat Mitigation Air gapped architecture severely constraints and deters insider threats.

Integrated Internal Audit Air gapped architecture ensures a continuous internal audit of all practices via separation of duty
and physical separation of environments.

Physical Separation An air gapped Secure Assembly facility limits access to physical actors

Chain of Custody Ensures fidelity of supplied components

9
Part of Quest Supply Chain Risk Management whitepaper for customers
 Responding to customers expectations

Security standards, regulations, frameworks

High Level NIST, CSA, ISO, FedRAMP, MS DPR, SOC, COBIT
What buyers ask for
- Compliance to Industry
frameworks
As much Automation of Demonstrates
Supports
Controls as possible

Technical Cloud Specific Best Practices

NIST, ISO, UK-NCSC, MS Azure, Amazon AWS
Detailed Level What internal
- Development stakeholders ask for
- Operations Technical Best Practices • Build-it-Right
- Security OWASP, CIS, SANS, FIPS 140-2,SDL • Deploy-it-Right
= DevSecOps • Operate-it-Right

10 Confidential
Teams Security and
Privacy activities
 Training Requirements Design Implementation Verification Release Response

Mandatory Awareness and Training – ISO 27001 compliance

1. Yearly Corporate Compliance Certification
• GDPR Compliance Training
• Information Security Policy Compliance Training
• Quest Code of Conduct Compliance Training
2. R&D Training (this training)
• Overall view of Security Program
• Details an activities during product creation/operation
• LinkedIn education:
• Developing Secure Software
• Programming Foundations: Secure Coding

Details on Wiki: https://wiki.labs.quest.com/display/MPM/Security+and+Privacy+training

12 quest.com | confidential
 Training Requirements Design Implementation Verification Release Response

– Security-By-Design
o R&D Best Practices will guide the team to areas requiring attention.
o FIPS 140-2 – Cryptographic approved functions and self-affirmation.
o Secure Coding
> OWASP – Top 10 errors, OWASP ASVS (175 technical controls)
> SANS – Top 25 errors
o ISO Requirements (SaaS)
o GA Checklist Requirements (SaaS)
o FedRAMP Requirements (SaaS)

– Privacy-By-Design
o Understand customer data collected, minimize Personally Identifiable Information
o Due diligence on sub-processors

– The team’s DoD needs to reflect that security is part of the delivery of a feature/story

Before starting a new release the Project Manager should schedule a meeting with Security Team

13 quest.com | confidential
 Training Requirements Design Implementation Verification Release Response

Full list: OWASP Top 10

14 quest.com | confidential
 Training Requirements Design Implementation Verification Release Response

Basic Security Concepts: considers these when coding or doing code reviews

15 quest.com | confidential
 Training Requirements Design Implementation Verification Release Response

Basic Security Analysis of your Architecture and Designs: Threat Modeling

16 quest.com | confidential
 Training Requirements Design Implementation Verification Release Response

Threat Modeling – Threat decomposition: STRIDE Technique

17 quest.com | confidential
 Training Requirements Design Implementation Verification Release Response

• Static Application Security Testing (SAST)

• Coverity for on-prem, Veracode for SaaS
• Team must use it at least a few times during your development
• Dynamic Application Security Testing (DAST)
• Mostly used for Web applications, port scanning, Http headers, certificate, fuzzing, etc.
• Acunetix - Monthly scans of On Demand
• Pen Testing – Interactive Application Security Testing (IAST)
• Yearly ISO mandatory Third-Party testing
• Gary Zheng: Burp Suite, ZAP
• Software Composition Analysis -Third-Party components
• WhiteSource: detect known vulnerabilities from NVD, MITRE CWE, MITRE CVE with CVSS scoring
• SaaS teams must scan regularly or as 3PC changes

18 quest.com | confidential
 Training Requirements Design Implementation Verification Release Response

• For SaaS teams to get ready for successful release:

– In advance of GA (end as needed afterward):
o Schedule a review of ISO deliverables with Security team
> OWASP ASVS
> Detailed Network Diagrams
> Security Incident Response PSIRT
> Security Guide
o Schedule a review of GA Checklist with DevOps and Security teams
> DR Technical procedure
> Incident Response Pager Duty
> Integration in Status Page

19 quest.com | confidential
 Training Requirements Design Implementation Verification Release Response

• Vulnerability Management
• Quest Vulnerability Response process: https://support.quest.com/essentials/reporting-security-vulnerability
• Resolution Timelines:
Using the CVSS Severity scoring:
• Critical Severity: within 10 calendar days.
• High Severity: within 30 calendar days
• Medium Severity: 60 calendar days
• Low Severity: 120 calendar days
• For SaaS teams
• Avenue Breach Policy: https://wiki.labs.quest.com/display/MPM/Security+Breach+Policy+Document
• Incident Response Process: https://wiki.labs.quest.com/display/MPM/Security+Incident+Process+Workflow
• Proper communication is key

20 quest.com | confidential
Detailed
Practices
FIPS 140-2
FIPS 140-2 Self Affirmation process
• Based on principle that MPM products only use Third-Party CVMP
validated modules. It covers the proper usage of FIPS approved
cryptographic functions and the mapping to these Third-Party NIST
certificates.
• 3 key templates established for MPM and adopted by other BUs:
– FIPS 140-2 Technical Product Assessment – Internal only
– FIPS 140-2 Self-Affirmation – Customer facing
– Deployment in FIPS environment – Customer facing
• Details documented on Wiki:
https://wiki.labs.quest.com/pages/viewpage.action?pageId=233359132

23 quest.com | confidential
FIPS 140-2 Compliant Cryptographic Algorithms
• Symmetric Encryption:  AES,  3DES (also known as Triple-DES and TDEA)
AES: 256 bit keys:  Acceptable
• 3DES:
• Three-key: Acceptable for "new applications". It is deprecated through 2023 and will be disallowed after 2023.
• Two-key: Disallowed

• Digital Signatures:  RSA(2048),  DSA,  ECDSA

• RSA:  len(n) ≥ 2048 (e.g. minimum 2048-bit keys/size of modulus) and in combination with SHA-2: Acceptable 
DSA:  len(p) ≥ 2048 AND len(q) ≥ 22: Acceptable 
ECDSA:  len(n) ≥ 224: Acceptable 

• Hashing:  SHA-1,  SHA-2 (-224, -256, -384, -512),  SHA-3 (-224, -256, -384, -512)
SHA-1: only permitted for non-digital signature applications. We advise the use of SHA-2 or SHA-3.

• Key derivation: PBKDF2

• HMAC Based: Acceptable, Note: Even HMAC-SHA1 is fine (so .Net Rfc2898DeriveBytes is fine with SHA1 but can support SHA256,
SHA512 as well).

• Much more details on Wiki

24 quest.com | confidential
Threat Modeling
Threat Modelling – Security-by-Design
• Threat Modeling is a process of assessing and documenting Security and Privacy risks. 
– Prioritize business security requirements.
– Identify and prioritize security risks early.
– Expose potential vulnerabilities.
– Detect security flaws in software architecture and design.
– Enable a defensive approach to software development.
– Great way to communicate the design more effectively to others.

• STRIDE Methodology: A step-by-step approach to the ‘CIA triad’.

– Builds a robust contextualized Threat Model.
– Help understand the Attack Surface of the system.
– Does not require in-depth security expertise of the team developing the threat model. No
pretention to know all the hackers’ tricks BUT
• It is a common language to work with a Security Team.
• Generate actionable output for detailed requirements documents.
• Drives effective application risk management decisions.
Threat Modelling Steps
• Profile the application:
– Physical Topology: Where and How the application is deployed
– Logical Topology: tiered architecture, dependencies
– Communication: Services, protocols, ports
– Identities, Roles: Access Control Matrix
– Nature of the Data
– Technology stack: Language, Frameworks

• Decompose the application

– Identify Entry Points
– Identify Exit Points
– Data Flow, Data sequence diagrams
– AuthZ, AuthN, Crypto
– Privileged Code
STRIDE
OWASP ASVS
 OWASP Application Security Verification Standard (ASVS 3.0.1)

ASVS is a list of application security requirements or tests that can be used by architects,
developers, testers, security professionals to define what a secure application is.
Objectives:
Use as a metric – Provide application developers and application owners with a yardstick with which to assess the
degree of trust that can be placed in their web applications.
Use as guidance – Provide guidance to security control developers as to what to build into security controls in order to
satisfy application security requirements.
Use during procurement – Provide a basis for specifying application security verification requirements in contracts

Security verification levels:

Level 1 is meant for all software.

Level 2 is for applications that contain sensitive data, which requires protection.
Level 3 is for the most critical applications that requires the highest level of trust.

34 Confidential
 Level 1: Recommended for all software
• Level 1 is intended to ensure that web applications are adequately protected
against application security vulnerabilities that are easy to discover, and
included in the OWASP Top 10 and other similar checklists.
• Level 1 controls can be ensured by a combination of automatic and manual
testing techniques. No access to source code is required.
• Threats to the application at this level are most likely from attackers looking
for “low-hanging fruits”. These are vulnerabilities which can be discovered
and exploited with simple techniques. Although the threat level for each
industry may vary, all industries are exposed to opportunistic attackers
looking for vulnerable applications on the internet. Level 1 is therefore
recommended for all applications.

35 Confidential
 Level 2: Recommended for applications that contain sensitive data

• An application achieves ASVS Level 2 if it adequately defends against most

of the risks associated with software today. In addition to penetration testing,
level 2 requires at least some access to developers, documentation, code,
and authenticated access to the system.
• Level 2 is typically appropriate for applications that handle significant
business-to-business transactions, including those that process healthcare
information, implement business-critical or sensitive functions, or process
other sensitive assets.
• Threats to Level 2 applications will typically be skilled and motivated
attackers focusing on specific targets using tools and techniques that are
highly practiced and effective at discovering and exploiting weaknesses
within applications.

36 Confidential
 OWASP ASVS Review and Scoring

37 Confidential
Vulnerabilities
Response
 Vulnerabilities Disclosure
Non-Disclosure
A vulnerability that may be reported to the vendor (or not), but is not disclosed to the public
regardless if the vendor decides to fix the vulnerability.

Full Disclosure
A vulnerability that is disclosed to the public, so both the vendor and the public find out about it at
the same time.

Coordinated Disclosure - also called “Responsible disclosure”

A vulnerability that is disclosed to the vendor, and after a reasonable period of time is disclosed to the
public. This type of disclosure are usually reported by Security Researchers – Ethical Hackers

Quest Vulnerability Response process goals is to avoid Full disclosure

39 Confidential
Vulnerabilities Disclosure
• Non-Disclosure
• A vulnerability that may be reported to the vendor (or not), but is not disclosed to the public
regardless if the vendor decides to fix the vulnerability.
• Full Disclosure
• A vulnerability that is disclosed to the public, so both the vendor and the public find out about it
at the same time.
• Coordinated Disclosure - also called “Responsible disclosure”
• A vulnerability that is disclosed to the vendor, and after a reasonable period of time is
disclosed to the public. This type of disclosure are usually reported by Security Researchers
– Ethical Hackers

Quest Vulnerability Response process goals is to avoid Full disclosure

40 quest.com | confidential
 Vulnerabilities Lifecycle

41 Confidential
Vulnerability Response Program
• One of the main reasons people contact CERT (Computer Emergency Response Team from
Carnegie Mellon Institute ) is to reach out to the vendor because the Ethical Hacker failed to
get any attention from the vendor
• In general, the Ethical Hacker will disclose publicly a vulnerability after 45 days of non-contact.

• Quest Vulnerability Response process:

https://support.quest.com/essentials/reporting-security-vulnerability
– Single intake form: https://support.quest.com/contact-us/report-security-vulnerability
– Acknowledgement page:
https://support.quest.com/essentials/vulnerability-reporting-acknowledgements

42 quest.com | confidential
Linked Education
 Self-Directed Security Education
• Training #1
• Developing Secure Software (Duration: 1 hour) - Course ID  418266
• https://www.linkedin.com/learning/developing-secure-software
• Training content:
• Understanding Software Security
• Software Security Threats
• Secure Software Design
• Secure Coding
• Testing for Security

• Training #2
• Programming Foundations: Secure Coding (Duration: 1 hour and 30 minutes) - Course ID  724800
• https://www.linkedin.com/learning/programming-foundations-secure-coding
• Training content:
• Security and Risk Overview
• Web Client Server Interaction Code Issues
• This App and Client-Server Interaction Issues
• Crypto and Security Misuse Issues
• Security in the SDLC
Your Manager will organize viewing sessions and/or make available Linked education licenses valid for at least 15 days
Feedback on these sessions or others you might view on Security learning is appreciated to customize future sessions

44 Confidential
Questions?
Thank you