Embed Size (px)
Citation preview
Secure Development Life Cycle for Your Infrastructure
Secure Development Life Cycle for Your Infrastructure
1
March 24, 2015Start Time: 9am US Pacific /12 noon US Eastern/ 5pm
London Time
TT
Sponsored by:Sponsored by:
2
#ISSAWebConf
WelcomeConference Moderator
WelcomeConference Moderator
3
March 24, 2015Start Time: 9am US Pacific
12pm US Eastern/5pm London Time
Vice President, South Florida ISSAJorge Orchilles
Speaker IntroductionSpeaker Introduction
• Michael F. Angelo- Chief Security Architect: NetIQ Corporation
• Hari Pendyala- Chief Advisor, Director: Zraddhaa Information Services
• Fred Kost- Vice President, Enterprise Marketing: Ixia
• Remember to type in your question in the Chat area of your screen. You may need to click on the double arrows to open this function.
• Michael F. Angelo- Chief Security Architect: NetIQ Corporation
• Hari Pendyala- Chief Advisor, Director: Zraddhaa Information Services
• Fred Kost- Vice President, Enterprise Marketing: Ixia
• Remember to type in your question in the Chat area of your screen. You may need to click on the double arrows to open this function.
4
Secure Development LifecycleSoftware Secure Development Lifecycle
Secure Development LifecycleSoftware Secure Development Lifecycle
Michael F. Angelo – CISSP, CRISCChief Security Architect
Michael F. Angelo – CISSP, CRISCChief Security Architect
AgendaAgenda
• Background
• History
• Software SDL
• Background
• History
• Software SDL
What is Security?What is Security?
• Security is like good food…
• Ultimately it is about – Analysis of Threats and Provisioning of Appropriate
Mitigations
• Security can be fuzzy
• Security is like good food…
• Ultimately it is about – Analysis of Threats and Provisioning of Appropriate
Mitigations
• Security can be fuzzy
What is SDL?What is SDL?
• SDL’s goal is to enable developers to provide defect free, trustworthy, programs by ongoing architectural design, implementation analysis, and testing.
• Note: Some believe that there can never be a 100% defect free, but that the goal should be to recover from a defect without introducing a vulnerability.
• SDL’s goal is to enable developers to provide defect free, trustworthy, programs by ongoing architectural design, implementation analysis, and testing.
• Note: Some believe that there can never be a 100% defect free, but that the goal should be to recover from a defect without introducing a vulnerability.
Building Security InBuilding Security In
• The best way to implement security is as part of the development lifecycle.– Steve Lipner – Senior Director Microsoft TWC
• The best way to implement security is as part of the development lifecycle.– Steve Lipner – Senior Director Microsoft TWC
As a Software DeveloperAs a Software Developer
• SDL reduces bugs
• SDL stops repeatable bugs
• Less Bugs = Less Updates, More time to add new features and ultimately improve customer satisfaction
• SDL reduces bugs
• SDL stops repeatable bugs
• Less Bugs = Less Updates, More time to add new features and ultimately improve customer satisfaction
SDL OverviewSDL Overview
• 7 Phases in MS Traditional SDL
• 5 Phases in Agile SDL– Training, Specification, Development, Release, Response
• 7 Phases in MS Traditional SDL
• 5 Phases in Agile SDL– Training, Specification, Development, Release, Response
Training Release Response
Training Release ResponseDesignRequirements VerificationImplementation
Specification Development
Phase 1 - Training SDLPhase 1 - Training SDL
• Prior to Development
• What not to do (common coding mistakes)– OWASP, SANS / MITRE
• What to do (Best practices)– safe calls– passwords– encryption– hashes
• Prior to Development
• What not to do (common coding mistakes)– OWASP, SANS / MITRE
• What to do (Best practices)– safe calls– passwords– encryption– hashes
OWASP Top 10 VulnerabilitiesOWASP Top 10 Vulnerabilities• Injection Attacks
• Broken Authentication and Session
• Cross-Site Scripting (XSS)
• Insecure Direct Object References
• Security Misconfiguration
• Sensitive Data Exposure
• Missing Functional Level Access Control
• Cross-Site Request Forgery (CSRF)
• Using Components with Known Vulnerabilities
• Un-validated Redirects and Forwards.
• Injection Attacks
• Broken Authentication and Session
• Cross-Site Scripting (XSS)
• Insecure Direct Object References
• Security Misconfiguration
• Sensitive Data Exposure
• Missing Functional Level Access Control
• Cross-Site Request Forgery (CSRF)
• Using Components with Known Vulnerabilities
• Un-validated Redirects and Forwards.
SANS/MITRE Top 25 Programming ErrorsSANS/MITRE Top 25 Programming Errors• CWE-89 Improper Neutralization of Special
Elements used in an SQL Command ('SQL Injection')
• CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
• CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
• CWE-434 Unrestricted Upload of File w/ Dangerous Type
• CWE-352 Cross-Site Request Forgery (CSRF)
• CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
• CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
• CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
• CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
• CWE-434 Unrestricted Upload of File w/ Dangerous Type
• CWE-352 Cross-Site Request Forgery (CSRF)
• CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
Insecure Interaction between Components
SANS/MITRE Top 25 Programming ErrorsSANS/MITRE Top 25 Programming Errors• CWE-120 Buffer Copy w/o Checking Size of Input
• CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
• CWE-494 Download of Code Without Integrity Check
• CWE-829 Inclusion of Functionality from Untrusted Control Sphere
• CWE-676 Use of Potentially Dangerous Function
• CWE-131 Incorrect Calculation of Buffer Size
• CWE-134 Uncontrolled Format String
• CWE-190 Integer Overflow or Wraparound
• CWE-120 Buffer Copy w/o Checking Size of Input
• CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
• CWE-494 Download of Code Without Integrity Check
• CWE-829 Inclusion of Functionality from Untrusted Control Sphere
• CWE-676 Use of Potentially Dangerous Function
• CWE-131 Incorrect Calculation of Buffer Size
• CWE-134 Uncontrolled Format String
• CWE-190 Integer Overflow or Wraparound
Risky Resource Management
SANS/MITRE Top 25 Programming ErrorsSANS/MITRE Top 25 Programming Errors• CWE-306 Missing Authentication for Critical Function
• CWE-862 Missing Authorization
• CWE-798 Use of Hard-coded Credentials
• CWE-311 Missing Encryption of Sensitive Data
• CWE-807 Reliance on Untrusted Inputs in a Security Decision
• CWE-250 Execution with Unnecessary Privileges
• CWE-863 Incorrect Authorization
• CWE-732 Incorrect Permission Assignment for Critical Resource
• CWE-327 Use of a Broken or Risky Cryptographic Algorithm
• CWE-307 Improper Restriction of Excessive Authentication Attempts
• CWE-759 Use of a One-Way Hash without a Salt
• CWE-306 Missing Authentication for Critical Function
• CWE-862 Missing Authorization
• CWE-798 Use of Hard-coded Credentials
• CWE-311 Missing Encryption of Sensitive Data
• CWE-807 Reliance on Untrusted Inputs in a Security Decision
• CWE-250 Execution with Unnecessary Privileges
• CWE-863 Incorrect Authorization
• CWE-732 Incorrect Permission Assignment for Critical Resource
• CWE-327 Use of a Broken or Risky Cryptographic Algorithm
• CWE-307 Improper Restriction of Excessive Authentication Attempts
• CWE-759 Use of a One-Way Hash without a Salt
Porous Defenses
#1 Coding Principle#1 Coding Principle• Validate All User Controlled Input
• Failure to validate– 5/10 OWASP Top 10– 14/25 of MITRE/SANS Top 25
• User controlled = attacker controlled data
• Check size / type before using, copying, passing on– Blacklists vs. whitelists– Proper encoding (UTF8/16)– Files too!
• Server - do not trust client validation
• Validate All User Controlled Input
• Failure to validate– 5/10 OWASP Top 10– 14/25 of MITRE/SANS Top 25
• User controlled = attacker controlled data
• Check size / type before using, copying, passing on– Blacklists vs. whitelists– Proper encoding (UTF8/16)– Files too!
• Server - do not trust client validation
Top 10 Best Coding PracticesTop 10 Best Coding Practices• Validate input
• Heed compiler warnings
• Architect and design for security policies
• Keep it simple
• Default deny
• Adhere to the principle of least privilege
• Sanitize data sent to other systems
• Practice defense in depth
• Use effective quality assurance techniques
• Adopt a secure coding standard
• Validate input
• Heed compiler warnings
• Architect and design for security policies
• Keep it simple
• Default deny
• Adhere to the principle of least privilege
• Sanitize data sent to other systems
• Practice defense in depth
• Use effective quality assurance techniques
• Adopt a secure coding standard
Training: PoliciesTraining: Policies
• Guidelines– Things we could do
• Best Practices– Things we should do
• Policies– Things we must do
• Guidelines– Things we could do
• Best Practices– Things we should do
• Policies– Things we must do
Training: Policies & PracticesTraining: Policies & Practices
• Passwords– Can’t be stored in the
clear!!!
• Passwords– Can’t be stored in the
clear!!!
• Best Practices – that are borderline policies…– DON’T write your own
encryption• Must use FIPS 140
validated algorithms• Must use standard
encryption– DO NOT COMPILE your
own version of OpenSSL• Use the standard
OpenSSL (FIPS enabled)
• Best Practices – that are borderline policies…– DON’T write your own
encryption• Must use FIPS 140
validated algorithms• Must use standard
encryption– DO NOT COMPILE your
own version of OpenSSL• Use the standard
OpenSSL (FIPS enabled)
Training: PoliciesTraining: Policies• 1 statement long
– Passwords must not be stored in the plaintext.
• Background information / explanation– Passwords stored in files can be stolen.
• Definitions (as appropriate)– Plaintext –text that can be read and understood
• Identified who can answer questions– Your Manager
• Identified executive sponsorship– VP of Engineering
• Identified penalty for failure to comply– Products ship will be delayed
• 1 statement long– Passwords must not be stored in the plaintext.
• Background information / explanation– Passwords stored in files can be stolen.
• Definitions (as appropriate)– Plaintext –text that can be read and understood
• Identified who can answer questions– Your Manager
• Identified executive sponsorship– VP of Engineering
• Identified penalty for failure to comply– Products ship will be delayed
Policies Don’t Change
Phase 2 – Specification - OverviewPhase 2 – Specification - Overview
• Secure Design– Features & Usage models– Follow Policies and Best Practices
• Handling mechanisms (Passwords, Keys, Sensitive data)
• Threat Modeling
• Secure Design– Features & Usage models– Follow Policies and Best Practices
• Handling mechanisms (Passwords, Keys, Sensitive data)
• Threat Modeling
Secure DesignSecure Design
Why Threat ModelingWhy Threat Modeling
• Identifies Attack Surface
• Provides Security Objective
• Minimizes Exposure
• Identifies Attack Surface
• Provides Security Objective
• Minimizes Exposure
Threat & Mitigation ModelsThreat & Mitigation Models
• Threat modeling – risk analysis– impact analysis– mitigations
• Should occur when:– new features are determined– when features are implemented– but before code freeze.
• Threat modeling – risk analysis– impact analysis– mitigations
• Should occur when:– new features are determined– when features are implemented– but before code freeze.
Threat Modeling – 4 ComponentsThreat Modeling – 4 Components
• Information– Top level product view– Architecture – files, permissions, protections, ports, etc.…
• Risk analysis– Spoofing, Tampering, Repudiation, Information leakage,
Denial of service, Elevation of Privilege (STRIDE)
• Impact analysis– Damage Potential, Risk, Exploitability, Affected Users,
Discoverability (DREAD)
• Mitigations– Based on Risks
• Information– Top level product view– Architecture – files, permissions, protections, ports, etc.…
• Risk analysis– Spoofing, Tampering, Repudiation, Information leakage,
Denial of service, Elevation of Privilege (STRIDE)
• Impact analysis– Damage Potential, Risk, Exploitability, Affected Users,
Discoverability (DREAD)
• Mitigations– Based on Risks
SDL – During DevelopmentSDL – During Development
• Static Code Analysis– compiler messages
• Code Reviews– manual– automatic
• Security Analysis– threat model verification– scanning / testing tools– hardening guides
• Static Code Analysis– compiler messages
• Code Reviews– manual– automatic
• Security Analysis– threat model verification– scanning / testing tools– hardening guides
Development ToolsDevelopment Tools
• Static Analysis Samples:– Compiler Warnings– http://en.wikipedia.org/wiki/List_of_tools_for_static_code_ana
lysis
• Profiling / Reconnaissance
• Exploit
• Fuzzing
• Scanning tools
• Static Analysis Samples:– Compiler Warnings– http://en.wikipedia.org/wiki/List_of_tools_for_static_code_ana
lysis
• Profiling / Reconnaissance
• Exploit
• Fuzzing
• Scanning tools
SDL – After ReleaseSDL – After Release
• Periodic Testing
• Other Things– Monitor CVE’s and threat board– Certifications
• Periodic Testing
• Other Things– Monitor CVE’s and threat board– Certifications
SDLC – Is Constantly EvolvingSDLC – Is Constantly Evolving
• Static Analysis Tools
• Knowledge– BugTraq– SlashDot
• 3rd Party Component Reviews
• Testing
• Static Analysis Tools
• Knowledge– BugTraq– SlashDot
• 3rd Party Component Reviews
• Testing
History / ResourcesHistory / Resources
• Microsoft– https://www.microsoft.com/security/sdl/
• OWASP – Top 10– https://www.owasp.org/index.php/Category:OWASP_Top_Te
n_Project
• DHS Software Assurance– https://www.dhs.gov/csd-swamp
• Microsoft– https://www.microsoft.com/security/sdl/
• OWASP – Top 10– https://www.owasp.org/index.php/Category:OWASP_Top_Te
n_Project
• DHS Software Assurance– https://www.dhs.gov/csd-swamp
Thank YouThank You
Michael F. Angelo – CISSP, CRISCChief Security Architect
Michael F. Angelo – CISSP, CRISCChief Security Architect
32
Question and AnswerQuestion and AnswerMichael F. Angelo – CISSP, CRISC
Chief Security [email protected]
To ask a question,type your question in the Chat area of your screen.
You may need to click on the double arrowsto open this function.
#ISSAWebConf
Michael F. Angelo – CISSP, CRISCChief Security Architect
To ask a question,type your question in the Chat area of your screen.
You may need to click on the double arrowsto open this function.
#ISSAWebConf
33
Secure Development Life Cycle – Audit Findings
Secure Development Life Cycle – Audit Findings
Hari Pendyala,
CISSP, CISM & ITIL Hari Pendyala,
CISSP, CISM & ITIL
OverviewOverview
• Frequently found issues during audits
• Recommendations
• Challenges
• Frequently found issues during audits
• Recommendations
• Challenges
36
Audit FindingsAudit Findings
• Access Control– Source Code Management
• No or Minimal access restriction to source code• No source code backup• Unrestricted access to backups
– Release Management• Developers access to production environment
• Access Control– Source Code Management
• No or Minimal access restriction to source code• No source code backup• Unrestricted access to backups
– Release Management• Developers access to production environment
37
Audit Findings – cont’dAudit Findings – cont’d
• Information Security Governance and Risk Management– Personnel Security
• Lack of background checks
– Awareness and Training• Non-existent SDLC training and SDLC process orientation• No Security Awareness and Training
• Information Security Governance and Risk Management– Personnel Security
• Lack of background checks
– Awareness and Training• Non-existent SDLC training and SDLC process orientation• No Security Awareness and Training
38
Audit Findings – cont’dAudit Findings – cont’d
• Software Development Security– SDLC policy
• No formal policy• If policy exists, but lacks enforcement
– Lack of Security Testing– No production data cleansing or improper cleansing
• Cryptography– Full access to crypto keys– Improper implementation of cryptography
• Software Development Security– SDLC policy
• No formal policy• If policy exists, but lacks enforcement
– Lack of Security Testing– No production data cleansing or improper cleansing
• Cryptography– Full access to crypto keys– Improper implementation of cryptography
39
Audit Findings – cont’dAudit Findings – cont’d
• Operational Security– No change management process– No incident management process
• Physical Security– Unauthorized access to code and related documentation
• Audits– No internal audits of SDLC process– No outsourced vendor audits– No audits of cloud based SDLC tools
• Operational Security– No change management process– No incident management process
• Physical Security– Unauthorized access to code and related documentation
• Audits– No internal audits of SDLC process– No outsourced vendor audits– No audits of cloud based SDLC tools
40
RecommendationsRecommendations
• Adopt one of the following maturity models– The Building Security In Maturity Model (BSIMM2)– Software Assurance Maturity Model (SAMM)– Systems Security Engineering Capability Maturity Model
(SSE-CMM)
• Follow guidelines from Static Analysis For safe Execution of Code (SAFECode) http://safecode.cs.illinois.edu/
• Adopt one of the following maturity models– The Building Security In Maturity Model (BSIMM2)– Software Assurance Maturity Model (SAMM)– Systems Security Engineering Capability Maturity Model
(SSE-CMM)
• Follow guidelines from Static Analysis For safe Execution of Code (SAFECode) http://safecode.cs.illinois.edu/
41
Recommendations – cont’dRecommendations – cont’d
• Perform application security testing– OWASP Testing Guide V3.0 recommends 9 types of Active
Security Testing categories as follows• Configuration Management Testing• Business Logic Testing• Authentication Testing• Authorization testing• Session Management Testing• Data Validation Testing• Denial of Service Testing• Web Services Testing • Ajax Testing (RIA Security Testing)
– Multi-tenant testing
• Perform application security testing– OWASP Testing Guide V3.0 recommends 9 types of Active
Security Testing categories as follows• Configuration Management Testing• Business Logic Testing• Authentication Testing• Authorization testing• Session Management Testing• Data Validation Testing• Denial of Service Testing• Web Services Testing • Ajax Testing (RIA Security Testing)
– Multi-tenant testing
42
Recommendations – cont’dRecommendations – cont’d
• Monitoring and Logging– Log audit findings– Peer code review findings– Security testing findings– Logging of application access
• Engage Information Security team early in the development cycle
• Monitoring and Logging– Log audit findings– Peer code review findings– Security testing findings– Logging of application access
• Engage Information Security team early in the development cycle
43
ChallengesChallenges
Applying security to ever-changing development environment
– Ex: Mobile App development
Applying security to ever-changing development environment
– Ex: Mobile App development
44
Question and AnswerQuestion and Answer
#ISSAWebConf #ISSAWebConf
45
Hari PendyalaCISSP, CISM & ITIL
COO, 7inQ
To ask a question,type your question in the Chat area of your screen.
You may need to click on the double arrowsto open this function.
46
Thank you!
Hari PendyalaCISSP, CISM & ITIL
COO, 7inQ
Secure Development Life Cycle for Your Infrastructure
Secure Development Life Cycle for Your Infrastructure
Fred Kost Vice President
Enterprise Marketing, Ixia
Secure Development LifecycleSecure Development Lifecycle
48
Source: Cisco and Microsoft
Breaches and Downtime: The CostsBreaches and Downtime: The Costs
49
TARGET SHARES TUMBLE AS RETAILER REVEALS COST OF DATA BREACHAlmost eight months after Target first revealed a data breach had compromised millions of its customers’ credit card and debit card information, the company is drilling down on what exactly the hack will cost shareholders (other than a CEO and a substantial dose of consumer trust). The number is
$148,000,000
Forbes, Aug 5, 2014
$300,000 per HourIndustry estimates on cost of downtime per an hour
What Was the Cause of the Breach?What Was the Cause of the Breach?
50© Ixia 2014
Source: Ponemon Institute – 2014 Cost of Data Breach Study: Global Analysis
Data Breach Root Cause Analysis
51
Changing and Moving FasterChanging and Moving Faster
52
53
F6F Hellcat
54
F/A 18 Hornet
New World Realities for IT InfrastructureNew World Realities for IT Infrastructure
• Speed and Agility
• DevOps
• Hybrid Cloud
• Continuous testing
• Virtualization
• Speed and Agility
• DevOps
• Hybrid Cloud
• Continuous testing
• Virtualization
55
High-performing organizations are still deploying code 30 times more frequently with 50 percent fewer failures than their lower-performing counterparts.
Source: Puppet Labs
Secure the Network Through Its LifecycleSecure the Network Through Its Lifecycle
56© Ixia 2014
Network
Does the hardware or
software solution work?
Is the solution setup ok for
your network?
Constant monitoring and
testing for aberrant behavior
Test any changes before you
introduce them
Does The Solution Work?Does The Solution Work?
57© Ixia 2014
Pre-Deployment• Vendor selection or POC• NGFW, FW, IPS, DLP…• Real world scenarios • Security resilience• Failover and load balancing• Your real applications• Focus on testing
Network
Is Solution Setup Ok For Your Network?Is Solution Setup Ok For Your Network?
58© Ixia 2014
Installing & Commissioning• Validate architecture• Establish baselines• DDoS mitigation readiness• Ensure visibility for
monitoring
Network
Can You Monitor for Aberrant Behavior?Can You Monitor for Aberrant Behavior?
59© Ixia 2014
Production Network• SIEM & security monitoring• Application intelligence• Network visibility• Virtualization visibility• Packet brokers
Network
Are You Testing Changes?Are You Testing Changes?
60© Ixia 2014
Software & Hardware
Upgrades• Change management• Changes in versions• New features• Configuration drift• Real-world testing
Network
NetworkOperation
Network Rollout
NetworkDesign
Validate
Secure
Optimize
Ixia ApproachApplication Performance andSecurity Resilience
Test and confirmdesign in virtual and
physical environments
Assess and monitor security threats in
real-world scenarios
Enhance application performance and
visibility across the network
• Validate network functions in pre- and post-deployment environments
• Optimize traffic across multiple infrastructures
• Ensure service level agreement (SLA) compliance
• Load balance between functions for optimal application performance
Application Performance Security Resilience
• Simulate real-world attacks and malware threats
• Deliver real-time threat intelligence for proactive protection
• Harden the resiliency of critical security devices
• Train cyber warriors for attack readiness
Ixia Solutions
For More InformationGet the e-bookFor More InformationGet the e-book
• Visit www.ixiacom.com• Visit www.ixiacom.com
63
Question and AnswerQuestion and Answer
Vice President
Enterprise Marketing, Ixia
To ask a question, typeyour question in the Chat area of your screen.
You may need to click on the double arrowsto open this function.
#ISSAWebConf
Vice President
Enterprise Marketing, Ixia
To ask a question, typeyour question in the Chat area of your screen.
You may need to click on the double arrowsto open this function.
#ISSAWebConf
65
Fred Kost
• Michael Angelo CISSP, CRISC
Chief Security Architect
• Hari PendyalaCISSP, CISM & ITIL v3
COO, 7inQ
• Fred Kost Vice President
Enterprise Marketing, Ixia
• Michael Angelo CISSP, CRISC
Chief Security Architect
• Hari PendyalaCISSP, CISM & ITIL v3
COO, 7inQ
• Fred Kost Vice President
Enterprise Marketing, Ixia
67
#ISSAWebConf
Open Panel with Audience Q&ATo ask a question,
type your question in the Chat area of your screen.You may need to click on
the double arrowsto open this function.
I would like to thank Michael, Hari and Fred for lending their time and expertise to this ISSA Educational Program. Thank you to IXIA for sponsoring this webinar.
Thank you Citrix for donating the Webcast service.
I would like to thank Michael, Hari and Fred for lending their time and expertise to this ISSA Educational Program. Thank you to IXIA for sponsoring this webinar.
Thank you Citrix for donating the Webcast service.
68
#ISSAWebConf
Closing Remarks
• Within 24 hours of the conclusion of this webcast, you will receive a link via email to a post Web Conference quiz.
• After the successful completion of the quiz you will be given an opportunity to PRINT a certificate of attendance to use for the submission of CPE credits.
• On-Demand Viewers Quiz Link• http://
www.surveygizmo.com/s3/2032246/ISSA-Web-Conference-Mar-24-2015-Secure-Development-Life-Cycle-for-Your-Infrastructure
• Within 24 hours of the conclusion of this webcast, you will receive a link via email to a post Web Conference quiz.
• After the successful completion of the quiz you will be given an opportunity to PRINT a certificate of attendance to use for the submission of CPE credits.
• On-Demand Viewers Quiz Link• http://
www.surveygizmo.com/s3/2032246/ISSA-Web-Conference-Mar-24-2015-Secure-Development-Life-Cycle-for-Your-Infrastructure
69
#ISSAWebConf
CPE Credit
