 Computer security policy ◦ Defines the goals and elements of an organization's computer systems  Definition can be ◦ Highly formal ◦ Informal  Security.

Slides:



Advertisements
Similar presentations
EMS Checklist (ISO model)
Advertisements

Secure Systems Research Group - FAU Process Standards (and Process Improvement)
Software Quality Assurance Plan
Information Risk Management Key Component for HIPAA Security Compliance Ann Geyer Tunitas Group
Chapter 5: Asset Classification
ITIL: Service Transition
Smart Grid - Cyber Security Small Rural Electric George Gamble Black & Veatch
DoD Information Technology Security Certification and Accreditation Process (DITSCAP) Phase III – Validation Thomas Howard Chris Pierce.
INDEX  Ethical Hacking Terminology.  What is Ethical hacking?  Who are Ethical hacker?  How many types of hackers?  White Hats (Ethical hackers)
Contractor Management and ISO 14001:2004
Security Controls – What Works
Information Security Policies and Standards
Developing a Records & Information Retention & Disposition Program:
Cybersecurity Summit 2004 Andrea Norris Deputy Chief Information Officer/ Director of Division of Information Systems.
Social Engineering Jero-Jewo. Case study Social engineering is the act of manipulating people into performing actions or divulging confidential information.
Information Systems Security Officer
Security Engineering II. Problem Sources 1.Requirements definitions, omissions, and mistakes 2.System design flaws 3.Hardware implementation flaws, such.
Secure System Administration & Certification DITSCAP Manual (Chapter 6) Phase 4 Post Accreditation Stephen I. Khan Ted Chapman University of Tulsa Department.
Pertemuan Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
NIST framework vs TENACE Protect Function (Sestriere, Gennaio 2015)
Computer Security: Principles and Practice
Vulnerability Assessments
Payment Card Industry (PCI) Data Security Standard
Purpose of the Standards
Session 3 – Information Security Policies
Network security policy: best practices
Security Architecture Dr. Gabriel. Security Database security: –degree to which data is fully protected from tampering or unauthorized acts –Full understanding.
Complying With The Federal Information Security Act (FISMA)
Information Asset Classification
Information Security Compliance System Owner Training Richard Gadsden Information Security Office Office of the CIO – Information Services Sharon Knowles.
Auditing Logical Access in a Network Environment Presented By, Eric Booker and Mark Ren New York State Comptroller’s Office Network Security Unit.
SEC835 Database and Web application security Information Security Architecture.
Lesson 8-Information Security Process. Overview Introducing information security process. Conducting an assessment. Developing a policy. Implementing.
Network Security Policy Anna Nash MBA 737. Agenda Overview Goals Components Success Factors Common Barriers Importance Questions.
Company Confidential How to implement privacy and security requirements in practice? Tobias Bräutigam, OTT Senior Legal Counsel, Nokia 8 October
Information Systems Security Computer System Life Cycle Security.
Security Baseline. Definition A preliminary assessment of a newly implemented system Serves as a starting point to measure changes in configurations and.
Presented to President’s Cabinet. INTERNAL CONTROLS are the integration of the activities, plans, attitudes, policies and efforts of the people of an.
NIST Special Publication Revision 1
How Hospitals Protect Your Health Information. Your Health Information Privacy Rights You can ask to see or get a copy of your medical record and other.
Security Architecture
Important acronyms AO = authorizing official ISO = information system owner CA = certification agent.
Best Practices: Financial Resource Management February 2011.
Service Transition & Planning Service Validation & Testing
Sample Security Model. Security Model Secure: Identity management & Authentication Filtering and Stateful Inspection Encryption and VPN’s Monitor: Intrusion.
ISO17799 Maturity. Confidentiality Confidentiality relates to the protection of sensitive data from unauthorized use and distribution. Examples include:
Ali Pabrai, CISSP, CSCS ecfirst, chairman & ceo Preparing for a HIPAA Security Audit.
The Culture of Healthcare Privacy, Confidentiality, and Security Lecture d This material (Comp2_Unit9d) was developed by Oregon Health and Science University,
Database Security and Auditing: Protecting Data Integrity and Accessibility Chapter 1 Security Architecture.
Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP.
Data Governance 101. Agenda  Purpose  Presentation (Elijah J. Bell) Data Governance Data Policy Security Privacy Contracts  FERPA—The Law  Q & A.
CSCE 548 Secure Software Development Security Operations.
5/18/2006 Department of Technology Services Security Architecture.
Information Security IBK3IBV01 College 2 Paul J. Cornelisse.
ISO/IEC 27001:2013 Annex A.8 Asset management
International Security Management Standards. BS ISO/IEC 17799:2005 BS ISO/IEC 27001:2005 First edition – ISO/IEC 17799:2000 Second edition ISO/IEC 17799:2005.
Database Security and Auditing: Protecting Data Integrity and Accessibility Chapter 1 Security Architecture.
Information Security tools for records managers Frank Rankin.
HHS Security and Improvement Recommendations Insert Name CSIA 412 Final Project Final Project.
Important acronyms AO = authorizing official ISO = information system owner CA = certification agent.
INFORMATION ASSURANCE POLICY. Information Assurance Information operations that protect and defend information and information systems by ensuring their.
Risk Controls in IA Zachary Rensko COSC 481. Outline Definition Risk Control Strategies Risk Control Categories The Human Firewall Project OCTAVE.
Security Methods and Practice Principles of Information Security, Fourth Edition CET4884 Planning for Security Ch5 Part I.
Computer Security: Principles and Practice First Edition by William Stallings and Lawrie Brown Lecture slides by Lawrie Brown Chapter 17 – IT Security.
Security Policies.
Security Policies.
Introduction to the Federal Defense Acquisition Regulation
I have many checklists: how do I get started with cyber security?
Chapter 8 Developing an Effective Ethics Program
Neopay Practical Guides #2 PSD2 (Should I be worried?)
Presentation transcript:

 Computer security policy ◦ Defines the goals and elements of an organization's computer systems  Definition can be ◦ Highly formal ◦ Informal  Security policies are enforced by organizational policies or security mechanisms

 The technical implementation defines whether a computer system is secure or insecure  The formal policy models can be categorized into the core security principles of: ◦ Confidentiality ◦ Integrity ◦ Availability  For example: ◦ Bell-La Padula model Bell-La Padula model  A confidentiality policy model ◦ Biba model Biba model  An integrity policy model

 A document that outlines the rules, laws and practices for computer and network access  Regulates how an organization will manage, protect and distribute its sensitive information ◦ Both corporate and client information  Lays the framework for the computer- network-oriented security of the organization From:

 Confidentiality ◦ Ensures the people who are authorized to have access to information are able to do so when needed ◦ Keeps valuable information only available to those people who are intended to see it  Prevents unauthorized access

 Integrity ◦ Maintains the value and the state of information   protected from unauthorized modification  Information only has value if we know that it's correct ◦ Major objective of information security policies is to ensure that information is not modified or destroyed or subverted in any way

 Availability ◦ Ensuring that information and information systems are available and operational when they are needed ◦ Major objective of an information security policy must be to ensure that information is always available to support critical business processing

 Policies ◦ Rules or guidelines to ensure how to do or don't do something  Practices ◦ How the polices are done  Policies and practices together: ◦ What should be done ◦ How to do it

 Management support  Structure to support it  Money to do it  Culture of security Expand on each here

 Military Model  Bell-LaPadula Model  Your own method

 Levels of classification e.g.: ◦ Secret ◦ Confidential ◦ Restricted ◦ Unclassified  Each has its rules of access ◦ Who may access ◦ How it may be access ◦ Are copies permitted?

 Basically simplified Military Model ◦ Relies on an ordering of access  Secret ◦ > Confidential  > Restricted  > Unclassified

 What works for your organization ◦ Policies and procedures that match your organizational needs ◦ Identify the needs ◦ Develop policies to meet the needs ◦ Develop procedures  Implement the policies  Enforce the policies ◦ (Monitor and update as needed)

 Policies and their owners  Technical Guides  System owners  What does the Policy cover

 Physical Security  Network Security  Access Control  Authentication  Encryption  Key Management  Compliance  Auditing and Review  Security Awareness  Incident Response & Disaster Contingency Plan  Acceptable Use Policy  Software Security

 Private company ◦ Specializes in internet security training ◦

 1.0 Purpose ◦ To empower InfoSec to perform periodic information security risk assessments (RAs) for the purpose of determining areas of vulnerability, and to initiate appropriate remediation.  2.0 Scope ◦ Risk assessments can be conducted on any entity within or any outside entity that has signed a Third Party Agreement with. RAs can be conducted on any information system, to include applications, servers, and networks, and any process or procedure by which these systems are administered and/or maintained.  3.0 Policy ◦ The execution, development and implementation of remediation programs is the joint responsibility of InfoSec and the department responsible for the systems area being assessed. Employees are expected to cooperate fully with any RA being conducted on systems for which they are held accountable. Employees are further expected to work with the InfoSec Risk Assessment Team in the development of a remediation plan.  4.0 Risk Assessment Process ◦ For additional information, go to the Risk Assessment Process.  5.0 Enforcement ◦ Any employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.  6.0 Definitions ◦ Terms Definitions ◦ Entity Any business unit, department, group, or third party, internal or external to, responsible for maintaining assets. ◦ Risk Those factors that could affect confidentiality, availability, and integrity of 's key information assets and systems. InfoSec is responsible for ensuring the Integrity, confidentiality, and availability of critical information and computing assets, while minimizing the impact of security procedures and policies upon business productivity.  7.0 Revision History

 1.0 Purpose ◦ The purpose of this policy is to define web application security assessments within. Web application assessments are performed to identify potential or realized weaknesses as a result of inadvertent misconfiguration, weak authentication, insufficient error handling, sensitive information leakage, etc. Discovery and subsequent mitigation of these issues will limit the attack surface of services available both internally and externally as well as satisfy compliance with any relevant policies in place.  2.0 Scope ◦ This policy covers all web application security assessments requested by any individual, group or department for the purposes of maintaining the security posture, compliance, risk management, and change control of technologies in use at. All web application security assessments will be performed by delegated security personnel either employed or contracted by. All findings are considered confidential and are to be distributed to persons on a “need to know” basis. Distribution of any findings outside of is strictly prohibited unless approved by the Chief Information Officer. Any relationships within multi-tiered applications found during the scoping phase will be included in the assessment unless explicitly limited. Limitations and subsequent justification will be documented prior to the start of the assessment.

 3.0 Policy ◦ Web applications are subject to security assessments based on the following criteria:  New or Major Application Release – will be subject to a full assessment prior to approval of the change control documentation and/or release into the live environment.  Third Party or Acquired Web Application – Will be subject to full assessment after which it will be bound to policy requirements.  Point Releases – will be subject to an appropriate assessment level based on the risk of the changes in the application functionality and/or architecture.  Patch Releases – will be subject to an appropriate assessment level based on the risk of the changes to the application functionality and/or architecture.  Emergency Releases – An emergency release will be allowed to forgo security assessments and carry the assumed risk until such time that a proper assessment can be carried out. Emergency releases will be designated as such by the Chief Information Officer or an appropriate manager who has been delegated this authority.

 3.1 Risk ◦ Security issues that are discovered during assessments will be mitigated based upon the following risk levels. Risk rating will be based on the OWASP Risk Rating Methodology  High  Any high risk issue must be fixed immediately or other mitigation strategies must be put in place to limit exposure before deployment.  Applications with high risk issues are subject to being taken off-line or denied release into the live environment.  Medium  Medium risk issues should be reviewed to determine what is required to mitigate and scheduled accordingly.  Applications with medium risk issues may be taken off-line or denied release into the live environment based on the number of issues and if multiple issues increase the risk to an unacceptable level. Issues should be fixed in a patch/point release unless other mitigation strategies will limit exposure.  Low  Issue should be reviewed to determine what is required to correct the issue and scheduled accordingly.  Remediation validation testing will be required to validate fix and/or mitigation strategies for any discovered issues of Medium risk level or greater.

 3.2 Tools ◦ The current approved web application security assessment tools in use which will be used for testing are:   … ◦ Other tools and/or techniques may be used depending upon what is found in the default assessment and the need to determine validity and risk are subject to the discretion of the Security Engineering team.

 3.3 Security Assessment Level ◦ Full  A full assessment is comprised of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide.  A full assessment will use manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered. ◦ Quick  A quick assessment will consist of a (typically) automated scan of an application for the OWASP Top Ten web application security risks at a minimum. ◦ Targeted  A targeted assessment is performed to verify vulnerability remediation changes or new application functionality.

 3.4 Duration ◦ The default duration of a web application assessment will be days time for the purpose of project planning and will be modified accordingly based upon the size and scope of the application functionality.  3.5 Exemptions ◦ Exemptions to the need for a security assessment will be made by the Chief Information Officer or delegated manager based on risk and criticality of needed application changes/functionality/architecture. Exemptions will assume the associated risk and will be documented as required by the change control policies.

 4.0 Responsibilities ◦ Security Engineering will be responsible for web application scoping, assessment, determination of discovered issue risk, and reporting to Project Management and application stakeholders. Project Management and application stakeholders will be responsible for the appropriate assessment scheduling and remediation efforts based upon assessment findings and Security Engineering recommendations.  5.0 Enforcement ◦ Web application assessments are a requirement of the change control process and are required to adhere to this policy unless found to be exempt. All application releases must pass through the change control process. Any web applications that do not adhere to this policy may be taken offline until such time that a formal assessment can be performed at the discretion of the Chief Information Officer.  6.0 Definitions ◦ Web Application  Any service that accepts and processes HTTP/HTTPS protocols. ◦ Major Release  A significant application software update/code change such as a new interface design programming platform change, etc. ◦ Point Release  An application software update/code change as part of the application lifecycle. ◦ Patch Release  An application software update/code change that addresses a bug or flaw.

 7.0 References ◦ OWASP Top Ten Project:  ◦ OWASP Testing Guide:  ◦ OWASP Risk Rating Methodology:   8.0 Revision History ◦ Version 1.0 – John Hally 1/4/11

 Must be monitored ◦ Are they being used/enforced? ◦ Are they sufficient?  Must be updated ◦ Every time a gap or lack is found

 At the least: ◦ CYA  Shows due diligence in protecting assets  Gives some legal protections  Ideally: ◦ Prevent successful attacks ◦ Saves $$$  Cost of attack  Later cost of same security later

Prevent Respond Improve Detect