advertisement

Security and SDLC May 2006

50 %
50 %
advertisement
Information about Security and SDLC May 2006
Entertainment

Published on August 11, 2007

Author: GenX

Source: authorstream.com

advertisement

Slide1:  Integrating Security into the System Development Life Cycle (SDLC) May 30, 2006 Center for Information Technology Office of the Deputy Chief Information Officer Larry Wlosinski, CDP, CISSP, CISM wlosinsl@mail.nih.gov Dan Goebel, CISSP, IAM/IEM goebeld@mail.nih.gov AGENDA (1st Half):  AGENDA (1st Half) Introduction Course Objectives/Background Risks Associated with Bad Programming Practices What is Security? How Things Changed Certification and Accreditation (Candamp;A) FIPS 200/NIST SP 800-53 What is the SDLC? Security and the 5 Phases of the SDLC AGENDA (2nd Half):  AGENDA (2nd Half) Metrics: Performance Measures, CPIC, Costs Programming Concerns and Safeguards Testing Top 10 Application Security Vulnerabilities Common Programming Errors Protection Against Parameter Tampering Responsibilities Helpful Reference Material Class Booklet:  Class Booklet Slides with Discussion Supplement to the NIH EMSP NIH SDLC IT Security Activities Matrix Sample Performance Measures Security Advice for Application Developers OWASP Top 10 Critical Web Application Security Vulnerabilities SDLC IT Security Responsibilities Certification Forms Course Objectives:  Course Objectives Provide an introduction to application security Provide a basic framework for system certification and accreditation Inform you about application related security services, functions, and responsibilities Provide useful information about programming concerns Provide pointers to security guidance (i.e. Best Practices) for programmers The Only Truly Secure Computer:  The Only Truly Secure Computer How Do We Give Away our Private & Sensitive Information? :  How Do We Give Away our Private andamp; Sensitive Information? People Steal It We Give it away Unintentionally We Give it away Intentionally Types of e-Crime:  Types of e-Crime Virus or malicious code Spyware Phishing Illegal generation of Spam Unauthorized access DoS attacks Rogue WAP Exposure of private or sensitive data Fraud Identity theft Password sniffing Theft of intellectual property Zombie machines on network Theft of other proprietary info. Sabotage Web site defacement Extortion Other Statistics2005 e-Crime Watch Survey:  Statistics 2005 e-Crime Watch Survey Sources of e-Crime: 82% Virus or Malicious Code 61% Spyware 57% Phishing (jumped from 31%) 48% Illegal Spam Generation Losses from Crimes: 55% Operational 28% Financial ($506,670 – mean) 12% Harm to reputation Culprit: 80% Outsiders; 20% Insiders Cyber Threat Groups*:  Cyber Threat Groups* Hackers – 37% Current employees – 18% Foreign entities – 6% Former employees – 5% Information brokers – 3% Current service providers/consultants/contractors – 2% Terrorists – 2% Customers – 2% Suppliers/business partners – 1% Competitors – 1% Former service providers/consultants/contractors – 1% Not sure – 21% *From 2005 E-Crime Watch Survey Computer Viruses & File Stripping by Half-Year:  Computer Viruses andamp; File Stripping by Half-Year Websense Blocking IT Security Categories (by Qtr.):  Websense Blocking IT Security Categories (by Qtr.) Websense Key Logger Events:  Websense Key Logger Events Slide14:  CIAC andamp; CERT IT Security Alerts by Year CIAC – D.O.E. Computer Incident Advisory Capability; US-CERT – U.S. Computer Emergency Readiness Team Applicable IT Security Legislation and Regulations:  Applicable IT Security Legislation and Regulations OMB A-130 (Appendix III) Federal Information Security Management Act (FISMA) Health Insurance and Portability and Accountability Act (HIPAA) Information Technology Management Reform Act (ITMRA) FIPS 200 (aka NIST SP 800-53) GAO* Report – Feb. 2006HHS Weaknesses in key program elements:  GAO* Report – Feb. 2006 HHS Weaknesses in key program elements Risk Assessments Policies and Procedures Security Plans Security Awareness and Training Tests and Evaluations of Control Effectiveness Remedial Actions (POAandamp;M) Incident Handling Continuity of Operations Plans *GAO = Government Accountability Office Risks:  Risks Financial Fraud Theft of Proprietary or Sensitive Info. Internal Attacks into Sensitive Applications (E.g. Human Resources, Patient Info., Grants, Financial Info.) Content Manipulation Loss of Customer Trust Unstable Application due to DoS attacks What is Security?:  What is Security? Confidentiality - Ensuring that there is no deliberate or accidental improper disclosure of sensitive automated information. Integrity - Protecting against deliberate or accidental corruption of automated information. Availability - Protecting against deliberate or accidental actions that cause automated information resources to be unavailable to users when needed. NIH IT Security Web Page - http://www.cit.nih.gov/security.html How Things Have ChangedHardware:  How Things Have Changed Hardware How Things Have ChangedSoftware and Data:  How Things Have Changed Software and Data How Things Have ChangedSystem Development Life Cycle:  How Things Have Changed System Development Life Cycle How Things Have ChangedIT Security:  How Things Have Changed IT Security How Things Have ChangedIT Security (Cont.):  How Things Have Changed IT Security (Cont.) Top Protective Technologies:  Top Protective Technologies Firewalls and automated virus scanning Physical security systems Spyware/adware detection software Intrusion detection systems Patch management Configuration management Access controls Wireless monitoring Encryption Two-factor authentication Certification and Accreditation(C&A):  Certification and Accreditation (Candamp;A) and FIPS 200/NIST SP 800-53 Certification and Accreditation (C&A) Process:  Certification and Accreditation (Candamp;A) Process System Definition andamp; Categorization Identify Candamp;A Approach Identify System Boundaries Update Candamp;A System Inventory Security Control Selection Risk Assessment Security Plan Verification of Security Control Effectiveness (Certification) Security Authorization (Accreditation) Post Accreditation Monitoring NIH Candamp;A Web Page - http://irm.cit.nih.gov/nihsecurity/NIH_System_Candamp;A.htm 1. System Categorization (Low, Moderate, High):  1. System Categorization (Low, Moderate, High) Determining System Impact Level Determine data classification (NIST SP 800-60 vol. I and II*) Use FIPS 199** if data type not in NIST SP 800-60 (i.e., C/I/A scoring) *NIST SP 800-60 Volumes I and II can be found at http://csrc.nist.gov/publications/nistpubs/index.html **FIPS 199 - http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf 1. System Categorization*:  1. System Categorization* Low-Impact – All 3 security objectives (C/I/A) are assigned a potential impact of low. Moderate-Impact – At least 1 security objective (C/I/A) is assigned impact value of Moderate and no objective of High High-Impact – At least 1 security objective (C/I/A) is assigned a value of High *FIPS 199/NIST SP 800-60 2. Identify C&A Approach:  2. Identify Candamp;A Approach System – Clearly identifiable system; includes Major Applications (MAs) and General Support Systems (GSS) Site – System grouped into single management location; primarily Data Centers Type – Appropriate when: Version similar to centralized version Targeted for deployment at multiple sites Platform similar at each site System controls tested one time at central facility Test results of system-specific controls are reused and site-specific controls are tested at each site after installation (e.g., VEDS, VSOF, SOFie) LAN – NIHnet managed, IC managed, or External 3. System Boundaries:  3. System Boundaries Assign information resources to a defined information system. Information resources include information, people, equipment, funds, and information technology. 4. Update C&A Inventory:  4. Update Candamp;A Inventory The Candamp;A inventory is used by the NIH ODCIO to track and monitor Candamp;A system activity and progress. This activity supports Federal Information System Management Act (FISMA), OMB, and OIG reporting requirements. IC ISSOs are responsible for maintaining and updating an Excel file provided by ODCIO with the system identification and description information, the impact/category level, point of contact information, planned deliverable/document dates, approving authorities and planned or actual signature dates. 5. Security Control Selection 17 IT Security Control Areas*:  5. Security Control Selection 17 IT Security Control Areas* AC - Access Controls AT - Awareness andamp; Training AU - Audit andamp; Accountability CA - Certification, Accreditation, andamp; Security Assessments CM - Configuration Mgt. CP - Contingency Planning IA - Identification andamp; Authentication IR - Incident Response MA - Maintenance MP - Media Protection PE - Physical andamp; Environmental Protection PL - Planning PS - Personnel Security RA - Risk Assessment SA - System andamp; Services Acquisition SC - System andamp; Communications Protection SI - System andamp; Information Integrity *From FIPS 200/NIST SP 800-53, Recommended Security Controls for Federal Information Systems System/Application Programming Requirements/Controls:  System/Application Programming Requirements/Controls AC-15: Program systems to mark output with distribution information [High] AC-16: Program system to label information in storage, process, and in transmission [Future] IA-7: Program authentication to system with encrypted data [All] SA-8: Design and implement systems using security engineering principles [Moderate] System/Application Programming Requirements/Controls (2):  System/Application Programming Requirements/Controls (2) SC-2: Program system to separate user interfaces from stored information [All] SC-16: Program system to pass security parameters to receiver [Future] SI-10: Program system to allow only acceptable data [Moderate] SI-11: Program system to handle error conditions [Moderate] Slide35:  Step 1: Characterize the System Step 2: Identify Vulnerabilities Step 3: Identify Threats Step 4: Identify Safeguards Step 5: Determine Likelihood Step 6: Perform an Impact Analysis Step 7: Determine Risk Step 8: Recommend Controls Step 9: Document Results 6. Risk Assessment Methodology 7. System Security Plan:  7. System Security Plan Definition - An IT System Security Plan documents the security requirements and security controls (management, operational, and technical) planned or in place for the protection of information and information systems. It delineates the responsibility and expected behavior of individuals who access the system. 7. Components of an IT System Security Plan:  7. Components of an IT System Security Plan Body of the Security Plan (SP) Template: http://irm.cit.nih.gov/security/secplantemp.html Rules of Behavior (ROB) http://irm.cit.nih.gov/security/nihitrob.html NIH Network Interconnection Security Agreement (ISA)/Memorandum of Agreement (MOA) http://irm.cit.nih.gov/security/RA_User_Cert_Agreemt.doc NIST SP 800-47, Security Guide for Interconnecting Information Technology Systems, September 200 7. Components of an IT System Security Plan (Cont.):  7. Components of an IT System Security Plan (Cont.) Configuration Management (CM) Plan* Defines Configuration Change Management Board (CCMB). Describes change request process. Contains test and evaluation procedures HHS Configuration Management Guide Privacy Impact Assessment (PIA)* HHS Privacy Impact Assessment Guide Contingency Plan (CP)* HHS IT Contingency Planning Guide *Optional as an appendix; required as part of Candamp;A package 8. Security Certification:  8. Security Certification 'A comprehensive analysis of the technical and non-technical aspects of an IT system in its operational environment to determine compliance to stated security requirements and controls.' Employs a set of structured verification techniques and verification procedures during the system life cycle Demonstrates the security controls for an IT system are implemented correctly and are effective Identifies risks to confidentiality, integrity, and availability of information and resources Ultimate Goal: Authorization to Process 8. Key Documents in C&A:  8. Key Documents in Candamp;A System Design Reviews (SDRs) Risk Assessments (RAs) System Security Plans (SSPs) Interconnection Agreements Security Test and Evaluation (STandamp;E) Reports Contingency Plan (CP) Disaster Recovery Plan (DRP) Corrective Action Plans (CAPs); POAandamp;M Certifier’s Statement/Letter – Certifying Authority (CA) Accreditation Letter – Designated Approving Authority (DAA) 9. System Accreditation:  9. System Accreditation 'A management decision by a senior agency official to authorize operation of an IT system based on the results of a certification process and other relevant considerations…' Assigns responsibility for the safe and secure operation of an IT system to a designated authority Balances mission requirements and the residual risks to an IT system after the employment of appropriate protection measures (security controls) States length of Authorization to Operate (ATO); if no major changes (maximum of 3 years) 10. Continuous Monitoring:  10. Continuous Monitoring The continuous tracking of changes to the information system that may affect the effectiveness of the security controls and the activities necessary for the continuing operation of the accredited system. System/Application Development Life Cycle (SDLC):  System/Application Development Life Cycle (SDLC) What is the SDLC?:  What is the SDLC? NIST SP 800-34 defines the SDLC as 'the scope of activities associated with a system, encompassing the system’s initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal that instigates another system initiation.' Information Security Life CycleThe Risk Framework:  Information Security Life Cycle The Risk Framework Starting Point Phases of the SDLC:  Phases of the SDLC Phase 1: Initiation:  Phase 1: Initiation Security Categorization - Data Sensitivity Assessment Preliminary Risk Assessment (RA) Review Solicitations (e.g. Request for Proposals - RFPs) Phase 2: Development/Acquisition:  Phase 2: Development/Acquisition Risk Assessment Functional and Technical Features/Requirements Cost Considerations and Reporting Staff background Checks Operational Practices Test Plans, Scripts, and Scenarios Security Controls in Specifications Phase 2: Development/Acquisition (2):  Phase 2: Development/Acquisition (2) In-House Concerns: Security features Development process Changing requirements Threats Vulnerabilities Malicious insiders Phase 2: Development/Acquisition (3):  Phase 2: Development/Acquisition (3) Contractor Hosted Concerns: Contract language Memorandum of Agreement (MOA)/Interconnection Security Agreements (ISAs) FIPS 200/NIST SP 800-53 compliance Configuration and change management 24x7 support for sponsored web applications Staff background checks Contingency and Disaster Recovery Plans Phase 2: Development/Acquisition (4):  Phase 2: Development/Acquisition (4) COTS Applications Operational Practices System Security Plan (SSP) Contingency Plan (CP) Awareness Training Documentation Phase 3: Implementation:  Phase 3: Implementation Testing and Acceptance Test Data Test unit, subsystem, and entire system (integration) Technical evaluation Security Management - administrative controls and safeguards Phase 3: Implementation (2):  Phase 3: Implementation (2) Physical facilities Personnel, responsibilities, job functions, and interfaces Procedures (e.g. backup, labeling) Use of commercial or in-house services Contingency Plans Phase 3: Implementation (3):  Phase 3: Implementation (3) Disaster Recovery Plan (DRP) COTS products (maintain up-to-date security patches) Remove installation programs Machine content/intent File and program overlay settings and privileges Phase 3: Implementation (4):  Phase 3: Implementation (4) Backup, restore, and restart instructions and procedures Implementation backups (could server as benchmark) Penetration Testing Ensure implementation of only certified and approved/accredited systems Phase 4: Operations/Maintenance:  Phase 4: Operations/Maintenance Configuration and change management Patch management Backup and restoration parameters Performing backups Support training classes Cryptography keys User administration and access privileges Audit logs Phase 4: Operations/Maintenance (2):  Phase 4: Operations/Maintenance (2) Log file analysis Security software Physical protection Off-site storage Output distribution Software andamp; hardware warrantees Registration/Deregistration Phase 4: Operations/Maintenance (3):  Phase 4: Operations/Maintenance (3) Operational Assurance Activities: Review runtime operation Review technical controls Verify documentation of access permissions Review system interdependencies Verify that documentation is current Verify proper use of deregistration Verify that documentation is accurate Continuous Monitoring Phase 5: Disposal:  Phase 5: Disposal Storage of cryptographic keys Legal requirements of records retention Archiving federal information Sanitize media Dispose of hardware and software BREAK:  BREAK Metrics:  Metrics Performance Measures CPIC Security Costs Performance Measures - Why:  Performance Measures - Why Quantify Benefit/Cost Analyses Budget Monitoring Quality Control/Improvement Regulatory Reporting Performance Measures:  Performance Measures Meeting the privacy, integrity, confidentiality, availability of the system as defined in the 'statement of work' or 'statement of need' Number and type of applications Labor hours spent on IT Security Magnitude and duration of effort Number of individuals involved Dollars associated with IT Security NIST Security Metrics:  NIST Security Metrics NIST SP 800-55, Security Metrics Guide for Information Technology Systems NIST SP 800-80, Guide for Developing Performance Metrics for Information Security NIST Guidance - http://csrc.nist.gov/publications/nistpubs/index.html CPIC* Phases:  CPIC* Phases Select – Identify and analyze each investment and select those that best support NIH’s mission Control – NIH reviews cost, schedule, and performance goals (EVM**) Evaluate – Identify any project changes or modifications that may be needed and revise the process based on lessons learned *CPIC = Capital Planning and Investment Control; **EVM = Earned Value Management CPIC Review Criteria:  CPIC Review Criteria HHS Interoperability Cross-cutting New Technology HHS CIO Interest Annual Costs Life Cycle Costs 10% Cost, Schedule, or Performance variance NIH Trans-NIH Mandates NIH CIO’s Designation Critical Infrastructure Performance Deficit * (7% Cost, Schedule, or Performance variance) Annual Cost Life Cycle Costs Department Review * This criterion only applies to investments previously selected through the CPIC process to be included in the NIH IT investment portfolio. CPIC Control Review Schedule:  CPIC Control Review Schedule More information on CPIC can be found at http://irm.cit.nih.gov/itmra/CPIC.html Tracking Security Costs:  Tracking Security Costs Background checks of employees Developing security requirements for the project Developing RFA (Request for Application) Reviewing RFP (Request for Proposal) Developing contingency program Back-up processing Tracking Security Costs (2):  Tracking Security Costs (2) Off-site storage of back-up media Developing security test program Exercising security test plans Training: Managers, Users, Operational Staff, LAN Administrators, Local Support Staff, Security Staff, etc. Programming Concerns and Safeguards:  Programming Concerns and Safeguards Programming Concerns and Safeguards:  Programming Concerns and Safeguards Access Controls System and Data Integrity Unauthorized Access Privacy and Confidentiality Production Implementation Documentation 1. Access Controls:  1. Access Controls Require a User ID and password SQL command concerns Allow only valid accounts Encrypt passwords Use strong passwords Beware of disks/CDs in reader Do not program as administrator Single Sign-On 2. System & Data Integrity:  2. System andamp; Data Integrity Check contractor disks Software upgrades and patches Program for versatility Allow only acceptable parameters Restrict use of configuration files Do not store parameters in system registers Edit data for size and value 2. System & Data Integrity (2):  2. System andamp; Data Integrity (2) Avoid using pathnames Allow only acceptable error codes Don’t retrieve data from public files Don’t use undocumented, seldom used, or unusual functions or commands Control quantity and size of files Limit number of processes running at one time Web – update cookies via on-line access Encrypt sensitive or critical data 3. Unauthorized Access:  3. Unauthorized Access Avoid commands that hackers can find in log files Avoid using hidden fields Do not store sensitive data on web control pages Avoid using cookies Use compiled code in production 3. Unauthorized Access (2):  3. Unauthorized Access (2) Check boundaries of test and data areas Verify completion of transmitted files Application should not require root access Determine what transactions should appear in log file 3. Unauthorized Access (3):  3. Unauthorized Access (3) Program controls so only applicable records exist and ensure they haven’t been altered When practical, use third party testers Write protect installation disks Separate reporting of financial transactions involving receipts and payments 4. Privacy and Confidentiality:  4. Privacy and Confidentiality Print ‘Sensitive Information’ on appropriate reports Do not store personal information in cookies Do not use persistent cookies 5. Production Implementation:  5. Production Implementation Ensure that all COTS software has latest security patches Remove installation programs from system Remove non-essential programs Verify operating system and relevant COTS products have latest upgrades and patches 5. Production Implementation (2):  5. Production Implementation (2) Check runtime privileges Review backup and restore procedures including checkpoint restart Backup immediately after installation Only implement systems that have had IVandamp;V and have been certified and accredited 6. Documentation Concerns:  6. Documentation Concerns User Access Privileges Deregistration - Implement procedures to control access when staff leave Operations, System, User, and Programming - documentation is to be kept current Contingency Plans (CP) , Continuity of Operations (COOP), and Disaster Recovery (DRP) Testing Plan and Results Testing:  Testing Common Programming Errors:  Common Programming Errors Failure to Adhere to the Design Improper Error Detection and Handling Buffer Overflows Improper Input Validation Un-initialized Variables Format String Attacks Erroneous Locking Routines Code Reviews only after Implementation Top 10 Web Application Security Vulnerabilities:  Top 10 Web Application Security Vulnerabilities Un-validated parameters Broken Access Controls Broken Account and Session Management Cross-Site Scripting Flaws Buffer Overflows Top 10 Web Application Security Vulnerabilities (Cont.):  Top 10 Web Application Security Vulnerabilities (Cont.) Command Injection Flaws Error Handling Problems Insecure Use of Cryptography Remote Administration Flaws Web and Application Server Mis-configurations System Testing and Evaluation (ST&E):  System Testing and Evaluation (STandamp;E) STandamp;E Plan Outline Sample Security Control Test Sheet STandamp;E Report Outline HHS Security Test and Evaluation Guide This information can be found at http://irm.cit.nih.gov/nihsecurity/NIH_System_Candamp;A.htm Protection Against Parameter Tampering:  Protection Against Parameter Tampering Data type restrictions (I.e. string, integer, real, etc.) Permit only the allowed character set Maximum and minimum length checking Check whether Null is allowed Protection Against Parameter Tampering (Cont.):  Protection Against Parameter Tampering (Cont.) Check whether parameter is required or not Check whether duplicates are allowed Numeric range checking Allow only specific legal values Allow only specific patterns Testing: Screen Contents:  Testing: Screen Contents Acceptable values Pre-filled fields Data length/field width Dates Field Capabilities Tab and Reverse Tab Keys Pull-downs Radio buttons Checkboxes Pop-ups Selection buttons Data retrieval Error messages Saving Multi-user Data import/upload Data export Web concerns Typical Screen Testing Checklist:  Typical Screen Testing Checklist Overall Concerns: Spacing Organization Screen Selection Tabs Help Screens Pop-up comments Printing Animation Section 508 Reality Check: Permissions Field interdependence Keyboard User Scenarios Response Time Compatibility Encryption Responsibilities:  Responsibilities Responsibilities:  Responsibilities Manager/Director Contract Officer Project Officer/Manager Budget Specialist Security Officer Application Developer/Programmer Database Manager LAN/System Administrators Application Trainers/Instructors IVandamp;V/Test Team IT Security Section Staff Responsibilities:  Responsibilities Manager/Director Contract Officer Project Officer/Manager Budget Specialist Security Officer* Application Developer/Programmer Database Manager LAN/System Administrators Application Trainers/Instructors IVandamp;V/Test Team IT Security Section Staff *More information on the responsibilities of the ISSO can be found in the ISSO group charter found at - http://www.cit.nih.gov/security-isso.asp Responsibilities:  Responsibilities Manager/Director Contract Officer Project Officer/Manager Budget Specialist Security Officer Application Developer/Programmer Database Manager LAN/System Administrators Application Trainers/Instructors IVandamp;V/Test Team IT Security Section Staff Responsibilities:  Responsibilities Manager/Director Contract Officer Project Officer/Manager Budget Specialist Security Officer Application Developer/Programmer Database Manager LAN/System Administrators Application Trainers/Instructors IVandamp;V/Test Team IT Security Section Staff Helpful Reference Material:  Helpful Reference Material NIST References:  NIST References URL for NIST Special Publications (SP): http://csrc.nist.gov/publications/nistpubs/index.html. 800-88, Guidelines for Media Sanitization, Feb. 2006 800-80, Guide for Developing Performance Metrics for Information Security 800-65, Integrating Security into the Capital Planning and Investment Control Process, Jan. 2005 800-64, Security Considerations in the Information System Development Life Cycle, Oct. 2003 800-55, Security Metrics Guide for Information Technology Systems, July 2003 800-53, Recommended Security Controls for Federal Information Systems, Feb. 2006 800-53A, Guide for Assessing the Security Controls in Federal Information Systems, July 2005 NIST References (2):  NIST References (2) URL for NIST Special Publications (SP): http://csrc.nist.gov/publications/nistpubs/index.html. 800-47, Security Guide for Interconnecting Information Technology Systems, Aug. 2002 800-44, Guidelines for Securing Public Web Servers, Sept. 2002 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems, May 2004 800-34, Contingency Planning Guide for Information Technology Systems, June 2002 800-30, Risk Management Guide for Information Technology Systems, July 2002 NIST References (3):  NIST References (3) URL for NIST Special Publications (SP): http://csrc.nist.gov/publications/nistpubs/index.html. 800-28, Guidelines on Active Content and Mobile Code, October 2001 800-27, Engineering Principles for Information Technology Security (A Baseline for Achieving Security), June 2001. 800-26, Security Self-Assessment Guide for Information Technology Systems, August 2005. 800-18, Guide for Developing Security Plans for Information Technology Systems, December 1998. 800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems, September 1996 Other References:  Other References NIH: Main IT Security Web Site: http://www.cit.nih.gov/security.html Candamp;A Web Page: http://irm.cit.nih.gov/nihsecurity/NIH_System_Candamp;A.htm IT Security Policies, Guidelines, and Regulations: http://irm.cit.nih.gov/security/sec_policy.html Configuration Management: http://www.cit.nih.gov/security-securing.asp CPIC: http://irm.cit.nih.gov/itmra/CPIC.html Office of Management and Budget (OMB) Circular No. A-130, 'Management of Federal Information Resources'. http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html HHS Policies and Guides: http://intranet.hhs.gov/infosec/policies_guides.html Carnegie Mellon Software Engineering Institute (SEI) Capability Maturity Model 2002: http://www.sei.cmu.edu/cmm/ Programming Advice:  Programming Advice 'Best Practices for Secure Web Development' URL: http://www.securitymap.net/sdm/docs/secure-programming/Secure-Web-Development.pdf W3C, 'The World Wide Web Security FAQ', 4 February 2002. URL: http://www.w3.org/Security/faq/www-security-faq.html Carnegie Mellon Software Engineering Institute CERT Coordination Center, 'Understanding Malicious Content Mitigation for Web Developers', 2 February 2000. URL: http://www.cert.org/tech_tips/malicious_code_mitigation.html PHP Freaks: 'JavaScript Security – JavaScript Manual'. URL: http://www.phpfreaks.com/javascript_manual/page/sec.htm Apache Software Foundation, 'Apache Cross Site Scripting Info', 2 February 2000. URL: http://www.apache.org/info/css-security References - OWASP:  References - OWASP A Guide to Building Secure Web Applications and Web Services, 7/27/05 http://easynews.dl.sourceforge.net/sourceforge/owasp/OWASPGuide2.0.1.pdf Securing Enterprise Web Applications at the Source: An Application Security Perspective http://www.owasp.org/docroot/owasp/misc/Securing_Enterprise_Web_Applications_at_the_Source.pdf Document Security in Web Applications, March 2005 http://www.owasp.org/docroot/owasp/misc/Document_Security_in_Web_Applications.doc The Ten Most Critical Web Application Security Vulnerabilities, 1/13/03 http://irm.cit.nih.gov/security/OWASP.pdf Microsoft Advice:  Microsoft Advice Microsoft Corporation, 'HOWTO: Prevent Cross-Site Scripting Security Issues', 1 February 2000. URL: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q252985 Microsoft Corporation, 'Q253119 HOWTO: Review ASP Code for CSSI Vulnerability', 2 February 2002. URL: http://support.microsoft.com/support/kb/articles/Q253/1/19.ASP Microsoft Corporation, 'Q253120 HOWTO: Review Visual InterDev Generated Code for CSSI Vulnerability', 2 February 2002. URL: http://support.microsoft.com/support/kb/articles/Q253/1/20.ASP Microsoft Corporation, 'Q253121 HOWTO: Review MTS/ASP Code for CSSI Vulnerability', 2 February 2002. URL: http://support.microsoft.com/support/kb/articles/Q253/1/21.ASP Articles - Metrics:  Articles - Metrics Frank, Diane, 'Agencies Seek Security Metrics.' Federal Computer Week, 19 June 2000. URL: http://www.fcw.com/fcw/articles/2000/0619/pol-metrics-06-19-00.asp Sirhal, Maureen, 'OMB orders agencies to report on computer security', 11 July 2002. URL: http://www.govexec.com/dailyfed/0702/071102td2.htm Burris, Peter, and Chris King. 'A Few Good Security Metrics.' METAGroup, Inc. 11 October 2000. URL: http://www.metagroup.com/metaview/mv0314/mv0314.html Questions?:  Questions?

Add a comment

Related presentations

Related pages

Secure Software Development Life Cycle Processes | Build ...

Secure Software Development Life Cycle Processes. ... aimed at security in the SDLC are ... Microsoft Security Advisories (2006). [Mills ...
Read more

Secure SDLC Cheat Sheet - OWASP

Secure SDLC Cheat Sheet. From OWASP. ... Every security practice contains a set of activities, ... OWASP projects may help to facilitate this.
Read more

Strengthening Ties Between Process and Security | Build ...

... Considerations in the SDLC Security Touchpoints ... Strengthening Ties Between Process and Security. ... 2006] McGraw, Gary. Software Security: ...
Read more

Systems development life cycle - Wikipedia, the free ...

The systems development life cycle (SDLC), ... developed to include the work from the SDLC process that may be conducted by ... 2006) SDLC RAD Open ...
Read more

Security in the software development life cycle

The software development life cycle, or SDLC, ... DNS rerouting by cloud security service providers may not be enough for DDoS mitigation when attackers ...
Read more

Security in All Phases of the Software Development Lifecycle

... today's typical software development lifecycle (SDLC) ... The emphasis on security in the SDLC at the ... and identify all the ways he may attempt to ...
Read more

Integrate Security Best Practices and Tools Into Software ...

Integrate Security Best Practices and Tools Into Software Development Life Cycle
Read more

Secure SDLC: Integrating security into your software ...

Integrating security into the SDLC is ... Secure SDLC: Integrating security into ... You also agree that your personal information may be ...
Read more