Plain English Guide To Common Criteria Requirements In The. Field Device Protection Profile Version 0.75

Size: px
Start display at page:

Download "Plain English Guide To Common Criteria Requirements In The. Field Device Protection Profile Version 0.75"

Transcription

1 Plain English Guide To Common Criteria Requirements In The Field Device Protection Profile Version 0.75 Prepared For: Process Control Security Requirements Forum (PCSRF) Prepared By: Digital Bond, Inc. June 14, 2006

2 Introduction Plain English Guide The Field Device Protection Profile was developed by the Process Control Security Requirements Forum (PCSRF) as a vehicle for the SCADA and Industrial Control System (ICS) community to express security requirements for the next generation field device. Examples of field devices include PLC s, PAC s, RTU s and IED s and are typically found in layer 1 or 2 of the ISA95 / Purdue CIM model. The field device security requirements were put in a Common Criteria Protection Profile to facilitate testing and certification of future field devices. The Common Criteria language and methodology can be difficult to understand. This document was created to help reviewers by making the requirements understandable without Common Criteria knowledge. This document is a translation and consolidation of the functional and assurance security requirements in the Field Device Protection Profile. It is a useful tool, but it is not a substitute for the Protection Profile. Vendors developing products and Security Targets should use the Protection Profile to work with the specific requirements the product will be tested against. How To Use This Document This document was developed for the following uses: 1. PCSRF members and other reviewers of the Protection Profile can use this document to understand the functional and assurance requirements in the Protection Profile without delving into the Common Criteria language and methodology. Comments made on this document will be used to update the Protection Profile and this document. 2. Other control system security efforts can use this document as input to procurement or requirement language projects. The Common Criteria is the result of an extensive effort by the IT security community and covers a broad range of security requirements. This document will help those groups working on procurement and requirements language to consider selected Common Criteria requirements without detailed study of the Common Criteria. 3. Asset owners and vendors can use this document in their efforts to develop, procure and deploy secure field devices. Requirements Audit The field device must have a robust audit capability. Each functional requirement has a list of mandatory events and information that must be recorded in an audit log. The field device vendor may also add to the required security related audit events and capabilities. Page 1

3 Plain English Guide The Administrator or Auditor roles determine what users are allowed to view the audit logs, while only the Auditor role is allowed to configure and manage the audit logs. Configuration can include determining what events and conditions are recorded, thresholds for alarms, and deletion of audit logs. The field device must prevent all users, including Administrators and Auditors, from modifying the audit logs. The field device shall record the date and time of the event, the user identity (if applicable), the system identity (if applicable), and the outcome of the event for every security related audit event. The field device shall have an indicator in each audit event that indicates if it is a security related audit event. Application Note: This requirement enables a security monitoring product or service to easily recognize and extract security events from the audit logs. The vendor may include more detail in the indicator such as the type of the security event, i.e. denial of service, authentication failure, or replay. The field device shall have the ability to monitor the accumulation and combination of audit events to identify the following potential security violations: - An Administrator specified number of user authentication failures - Replay of data or security parameters - Failure of periodic and on-demand self-tests - An Administrator specified number of encryption or decryption failures - An Administrator specified number of cryptographic data integrity verification failures The field device shall have an access control setting that allows an Administrator or Auditor to determine what users or roles have the ability to view audit records. The default setting shall be to deny access to all users except those in the Administrator or Auditor roles. The field device shall allow an Auditor to include or exclude the recording of audit events based on the following criteria: user identity, system identity, event type, and success or failure. The field device shall prevent any modifications to the audit records and only allow an Auditor to delete audit records. The field device shall generate an alarm and enter it in the audit log when the audit log reaches an Auditor set percentage of storage capacity. The field device audit log shall overwrite the oldest stored audit records when the audit log is full. Page 2

4 Plain English Guide Cryptography The field device may require a variety of cryptographic functions to, such as key management, encryption and decryption, and digital signature generation and verification. The Protection Profile does not require these functions, but there are requirements for any cryptographic functions used in the field device because the security of the cryptography is integral to the security of the field device. The protection profile specifies US Government FIPS standard for all cryptographic modules, functions and parameters. Other regions, countries and industry groups may choose to use a different standard. All cryptographic functions shall take place in a FIPS 140-2, Level 3 approved module. This module may be implemented in software, hardware or a combination of software and hardware. Key management, including key generation, distribution and destruction, shall be performed in a manner specified in FIPS All cryptographic functions, such as encryption, decryption, and digital signatures, shall be performed in a manner specified in FIPS Users Managing users and their access rights introduces many requirements. First users must be uniquely identified and have that identity authenticated. Next a variety of access control measures, such as role based and time based, determine what a user is authorized to do. Administrators, the role with the rights to manage users and security, determine the access control settings in the field device. The field device shall support at least five user roles: Administrator, Auditor, Display, Engineer, and Operator. The field device vendor may choose to support additional user roles or allow an Administrator to create additional roles. An Administrator shall be able to assign a user to more than one role. Application Note: The Protection Profile includes definition of the Administrator and Auditor roles through a set of requirements for those roles. The Operator, Engineer and Display roles do not have specific requirements, and their authorization rights would be determined by the field device vendor and the asset owner configuration. The field device shall maintain at least the following information for each user account: unique userid, data required to verify authentication credentials, user role membership, time and date when account is to be disabled, time of days and days of the week the account is allowed to login to the field device. Page 3

5 Plain English Guide The field device shall require two-factor authentication for all users in the Administrator role. At least one of the authentication factors shall prevent replay of authentication data. The field device shall support setting a password complexity requirement for each role. The complexity requirement shall include the capability to require no password authentication for a role. The password complexity requirements shall be configurable by an Administrator. Application Note: This requirement supports setting a lenient password complexity or even no password required for users in the Display role and a highly secure password complexity requirement for Auditors and Engineers. The field device shall detect when a user fails to authenticate an Administrator selectable consecutive number of times and write a security event to an audit log. The field device shall not allow any user action until the user is authenticated. The field device shall only state the login attempt failed after a failed login attempt. Application Note: The field device must not indicate whether the userid or the authentication credentials were the cause of the login failure The field device shall detect when users authenticating in an Administrator role replay authentication data. This replayed authentication data shall result in a failed authentication and a security event shall be written to the audit log. Access Control After a user or system is authenticated, the field device must implement access control to determine and enforce what is allowed and disallowed. The field device shall implement access control to all data points, configuration parameters and other objects in the field device. The access control decision shall be based on a variety of factors that are configured by an Administrator. The field device shall support at least the following access control factors: user role, system location, and time of day / day of week. Application Note: The requirement for access control based on system location is sometimes referred to as station based access control. A common example of use would be to allow a user to perform more actions from the control center than from the corporate network. The field device shall deny access to all data points, configuration parameters and other objects in the field device unless expressly permitted by an Administrator. Application Note: This is a default least privilege configuration. All exported data from the field device shall include, retain and enforce the security functions that are present while the data is in the field device. Page 4

6 Data Authentication Plain English Guide The integrity status of process data, configuration settings, user data and audit logs must be maintained and periodically verified. Unauthorized modification of this data could be the result of an attack or a software or hardware failure. In all cases it is important for the Operators to know the data may be unreliable and the Administrators to know the field device may have been attacked. The field device shall detect when audit log data, process data, data related to configuration settings, and user data has been corrupted or modified without authorization. The field device shall write a security event to an audit log when a data authentication failure has been identified. All data imported into the field device shall have security fields that allow the field device to identify and verify the source of the data and verify the data has not been modified in transit. An imported data authentication failure shall generate a security event in an audit log. Application Note: Remote management, polling, commands and all other communication sent to the field device must have the source and data authenticated before being accepted by the field device. This will identify man-inthe-middle attacks and spoofing attacks. All data exported from the field device shall have security fields that allow the recipient to identify and verify the source of the data and verify the data has not been modified in transit. Application Note: This requirement has multiple impacts. Regular responses to polls and other commands require authentication of the source (the field device) and the content. This will identify man-in-the-middle attacks and spoofing attacks. The requirement also will protect the integrity of data that might be exported and used to configure other field devices, as a backup record, or for other management and maintenance purposes. Rollback Rollback allows an Administrator to quickly recover from configuration and other management errors. The field device must support rollback by an Administrator. Requirement: The field device shall support Administrator rollback of the last, or an Administrator specified number of, management and configuration changes. Application Note: The field device must support rollback of at least one change, but the field device vendor may allow an Administrator to select a higher number of changes to rollback. Rollback is not limited to security functions because most configuration changes can affect integrity and availability. Page 5

7 Management Plain English Guide Secure management of the field device is essential to secure operation. Only users in the Administrator role are allowed to manage the security related parameters in the field device. The sole exception to this is the Auditor role manages most of the security related audit settings. Each functional requirement may have one or more associated security management functions. The field device must be configured to be secure out-of-the-box with the security related parameters set to a high security value. Management of field device functions related to authentication, authorization, data integrity, software integrity, non-repudiation, and denial of service protection shall be restricted to users in the Administrator role. The default settings of all security related parameters shall be set to a restrictive value that represents a high security configuration. A user in the Administrator role shall be able to modify these settings. Application Note: This is similar to efforts being deployed in many software applications where the default is now a secure setting rather than a permissive setting. All of these security parameters and there settings must be documented in the Administrator Guidance. Self Protection The software and hardware in the field device must be protected against cyber and physical attacks. In many cases preventing attacks is not possible, but the field device must detect attacks on its integrity and not allow improper operation. Self-tests must be run at start-up, periodically and on Administrator request to identify errors in the field device software. These errors could be the result of an attack or system failure. Tests of the cryptographic functions and other security parameters must be included in the self tests because once these functions stop working the field device is unprotected. The field device shall implement and run a suite of self-tests to verify it is running correctly. These self-tests shall be run at start-up, periodically during normal operation at an Administrator specified interval, and at the request of an Administrator. The self tests shall include tests of all cryptographic functions. Any self-test failures shall generate a security event in an audit log. The field device shall fail secure unless failing secure conflicts with a fail safe operation. Fail safe shall take priority over fail secure. Fail secure shall not allow operation affected by the failure to continue until the failure is corrected. Failures Page 6

8 Plain English Guide include conditions that cause a reboot or the loss of available computing memory or storage. Application Note: There may be conditions where fail safe operation causes the field device to be an insecure state. The field device vendor should design the product to avoid or limit fail safe / fail secure conflicts, but the Protection Profile realizes this may be unavoidable in some circumstances. The field device shall attempt to auto-recover from a failure by restarting some or all of the processes. During this recovery period the field device shall not allow any operation until the field device returns to a secure state. The field device shall detect unauthorized modification or corruption to the executable code and configuration parameters in the field device. A security event shall be entered in the audit log that lists the affected code or parameters. Physical tampering with the field device must be identifiable in a physical inspection. Physical tampering shall generate a security related event in an audit log. Application Note: The Protection Profile requires the field device to be tamper evident, not tamper resistant or tamper proof. The distinctions and requirements are well defined and tested in FIPS Denial of Service Protection It is impossible for a field device to stop all denial of service attacks. For example an attacker could use all available bandwidth and thereby prevent communication to the field device. The requirements in the Protection Profile focus on identifying and preventing denial of service attacks that aim to overwhelm computing resources in the field device. The field device shall assign a priority to each user and system that communicates with the field device. Use of all shareable resources, such as CPU and memory, shall be mediated on the basis of the assigned priorities. Application Note: System communication with the field device is often, but not always, run due to a user request. In this case the system would be assigned the priority of the users. Many control systems have system accounts that are not associated with a user, and these accounts must also be assigned a priority. An Administrator shall be able to assign maximum quotas for memory, processing power, and data storage for users and systems. The field device shall not allow the Administrator to configure the quotas to exceed a resources capability. The field device shall enforce the quota and issue a security related event to an audit log whenever the quota is reached. Page 7

9 Plain English Guide Time Source Time stamps are very important for field devices, and they must have access to a reliable time source. The field device shall be able to provide reliable time stamps for its own use. Application Note: The field device needs access to a reliable time source, but that time source does not need to be in the field device. Documentation Administrator Guidance Document The field device vendor must provide a document or set of documents that provides guidance on how to administer the field device in a secure manner. Requirement: The field device vendor shall provide an Administrator Guidance document. The document shall include: - A description of the administrative functions and interfaces - A list of all security parameters and recommended secure settings of these parameters. - All security events the field device generates and the related administrative action that should be taken. For example, an event indicating the audit log is almost full and how to save and clear the log. - A list of assumptions about user behavior necessary for secure operation. - A list of requirements for the IT environment the field device will reside in. User Guidance Document The field device vendor shall provide a document or set of documents that provides guidance for users that are not administrators. Requirement: The field device vendor shall provide a User Guidance document. The document shall include: - A description of the user-accessible security functions and the interfaces to these functions - A list of warnings related to user-accessible security functions that could affect the security of the field device - All user responsibilities necessary for the secure operation of a field device Page 8

10 Installation and Start-Up Procedures Plain English Guide Control of the field device changes from the vendor to the customer at delivery. The field device vendor is required to document the procedures to install and start-up the field device in a secure manner. This is a separate document from the User and Administrator Guidance documents. Requirement: The field device vendor shall provide a document with the procedures required for the secure installation and start-up of the field device. Field Device Product Development Secure Development Environment A member of the development team or someone with access to the development software, firmware or hardware could intentionally introduce a vulnerability into the field device. Examples include back doors, incorrect random number generation, fixed keys, and susceptibility to buffer overflows or other common attacks. The field device vendor shall have a documented development security program that covers the physical, procedural, personnel and other security measures to protect the confidentiality and integrity of the field device design and implementation. The field device vendor shall be able to provide evidence of compliance with the documented program and shall be available for audit. Design Documentation The field device vendor must have a documented set of requirements and a structured design process that insures the design meets this process. There are numerous assurance requirements related to the development methodology. The primary three requirements worthy of an end user review are the functional specification document, architectural design, and security design documentation. The field device vendor shall have a documented functional specification and make this available for inspection. The field device vendor shall have a documented architectural design that includes a description of the major subsystems and the interface between major subsystems. The document shall describe how the design meets all of the functional requirements and be available for inspection. The field device vendor shall identify and document all subsystems that play a role in meeting the security requirements. This security design document shall describe the security functions in the subsystem and be available for inspection. Page 9

11 Development Tools and Techniques Plain English Guide Development tools and techniques are used in the development of the field device. Examples include programming languages, runtime libraries, computer aided design (CAD) systems and implementation standards. These tools and techniques must be identified and all be well-defined. Well-defined implies industry standard or common tools and techniques that are easily considered applicable for the development without the need for further clarification. The field device vendor shall identify all development tools and only use tools that are well-defined. Configuration Management and Change Control The process of modifying the field device design or configuration must be well controlled to prevent unauthorized changes. Additionally, configuration management is involved in building one or more different versions of the product for delivery to customers. The process must uniquely identify each different build and configuration delivered by the vendor. The process must use an automated configuration management system to control changes and support generation of the field device. This process must include problem tracking for security flaws and their resolutions. When a valid distribution of the field device has been released by the vendor, the vendor must provide a means for the vendor and customer to identify any intentional or unintentional modification or corruption to the field device. The field device vendor shall use an automated configuration management system as part of the configuration management and change control process. The field device vendor shall document the configuration management and change control process, and this document shall be available for review and audit. This process shall also track all known security flaws and efforts at remediation of identified security flaws. The field device vendor shall have configuration management documentation for each unique version of the field device delivered to a customer that includes a configuration list with all components and parameters settings and an acceptance plan. The field device vendor shall identify and document all known security flaws and all security flaws corrected in the current version of the field device. Page 10

12 Plain English Guide The field device vendor shall provide a method for the vendor and customer to identify any modifications to a released version of the field device. Development Life Cycle There are opportunities for intentional and unintentional vulnerabilities to be added after the development phase of the field device product life cycle. For this reason the Protection Profile includes requirements for the entire product life cycle. The field device vendor shall describe the life cycle model used to develop and maintain the field device including the security controls and provide evidence the life cycle procedure is being followed. The life cycle procedure shall be available for audit. Fixing Security Vulnerabilities Security patches are an issue with most IT products. The SCADA community has had a mixed record on supporting security patches in the underlying operating system, related applications and the SCADA applications themselves. The Protection Profile requires the vendor have a documented program to correct identified flaws. Asset owners could include compliance with this program as a contractual obligation. The field device vendor shall have a documented flaw remediation procedure to address identified security vulnerabilities from any source. The procedure shall document how anyone can report a suspected flaw, how the flaw and remediation is tracked by the vendor, timelines for correcting the flaw, and how corrective actions (i.e. patches, administrative procedures, etc.) are provided to the purchasers of the field device. The process shall require a corrective action for each identified security flaw, and this correction is provided to all purchasers of the field device. Testing by the Developer The field device vendor is responsible for testing the field device and providing test documentation to prove proper implementation. Vendor testing required by the Protection Profile focuses on two areas: meeting the functional specifications and the interfaces between low-level modules in the field device. The functional testing demonstrates the field device satisfies the functional requirements, but it does not necessarily test that the field device does not identify or test additional Page 11

13 Plain English Guide functions that do not address functional requirements. The security of these additional functions is tested by the independent testing team. The vendor must document the test plan for each of the functional requirements. Where appropriate the vendor should test multiple functional requirements in various orders and frequency to test for resilience against timing attacks. The vendor must provide an analysis that the test plan adequately tests the functional requirements. The Protection Profile does not require exhaustive testing, with every possible value or option tested, but the vendor is responsible for proving the testing is appropriate. A field device, like most products, can be described as a set of low-level modules or subsystems, such as a CPU and input/output communication modules. There may be more than more than one low-level module on a module available for purchase in a field device. The vendor must identify the low-level modules in the design documentation and provide test documentation that the interface between these modules is as specified. The field device vendor shall provide testing documentation, including test plans, test procedure descriptions, expected test results and actual test results, for all field device functional requirements. The test documentation shall be available for audit. The field device vendor shall provide a document that shows an analysis of the testing that demonstrates the testing adequately covered all functional requirements. Independent Testing A testing group that is not part of the development team must repeat some or all of the functional testing by the Development group. The amount and type of testing is determined by this independent testing group. Additional tests may be developed and performed by the independent group if they believe it is required to verify correct implementation of the field device design. This group could be a Quality Assurance group in the vendor s organization or an independent lab. The field device vendor shall provide a test environment and test plans for independent testing. A group independent from the Development group shall exercise all or part of the test plans as required to verify the field device operates as specified. The test results shall be available for audit. The independent group shall consider if additional testing is required, and perform any testing they believe is required. The additional test plans, test procedure descriptions, expected test results and actual test results shall be documented and available for audit. Page 12

14 Vulnerability Assessment Plain English Guide The developer and independent testing verifies the field device works as specified in the functional requirements. The vulnerability assessment tests for exploitable vulnerabilities in the implementation, easily defeated security functions, vulnerabilities in recommended configuration parameters, vulnerabilities due to incorrect configuration, covert channels and a variety of other areas. The CCEVS introduces additional assurance requirements for the covert channel analysis. A covert channel is an unintended channel that provides information that may be used to help exploit the field device. The field device must be analyzed to identify any cover channels that leak critical security parameters. An independent third party shall perform a vulnerability assessment on the field device to determine if the field device can be exploited by a moderately skilled attacker. The assessor shall provide documentation that describes all tests, all test results, and any identified vulnerabilities. The field device vendor shall analyze the User Guidance, Administrator Guidance, and Installation Procedures to determine if there is clear, consistent and complete security guidance for all possible modes of operation. The guidance documentation shall include all assumptions about the environment and external security measures to maintain security. This analysis shall be documented and available for audit. The field device vendor or independent third party shall analyze the field device and identify any covert channels that leak critical security parameters. The analysis procedures and results must be documented, available for audit, and selectively validated by an independent third party. Page 13

Build (develop) and document Acceptance Transition to production (installation) Operations and maintenance support (postinstallation)

Build (develop) and document Acceptance Transition to production (installation) Operations and maintenance support (postinstallation) It is a well-known fact in computer security that security problems are very often a direct result of software bugs. That leads security researches to pay lots of attention to software engineering. The

More information

FIREWALL CHECKLIST. Pre Audit Checklist. 2. Obtain the Internet Policy, Standards, and Procedures relevant to the firewall review.

FIREWALL CHECKLIST. Pre Audit Checklist. 2. Obtain the Internet Policy, Standards, and Procedures relevant to the firewall review. 1. Obtain previous workpapers/audit reports. FIREWALL CHECKLIST Pre Audit Checklist 2. Obtain the Internet Policy, Standards, and Procedures relevant to the firewall review. 3. Obtain current network diagrams

More information

SECURITY PRACTICES FOR ADVANCED METERING INFRASTRUCTURE Elif Üstündağ Soykan, Seda Demirağ Ersöz 08.05.2014, ICSG 2014

SECURITY PRACTICES FOR ADVANCED METERING INFRASTRUCTURE Elif Üstündağ Soykan, Seda Demirağ Ersöz 08.05.2014, ICSG 2014 SECURITY PRACTICES FOR ADVANCED METERING INFRASTRUCTURE Elif Üstündağ Soykan, Seda Demirağ Ersöz 08.05.2014, ICSG 2014 Table of Contents Introduction AMI Communication Architecture Security Threats Security

More information

Summary of CIP Version 5 Standards

Summary of CIP Version 5 Standards Summary of CIP Version 5 Standards In Version 5 of the Critical Infrastructure Protection ( CIP ) Reliability Standards ( CIP Version 5 Standards ), the existing versions of CIP-002 through CIP-009 have

More information

05.0 Application Development

05.0 Application Development Number 5.0 Policy Owner Information Security and Technology Policy Application Development Effective 01/01/2014 Last Revision 12/30/2013 Department of Innovation and Technology 5. Application Development

More information

WIND RIVER SECURE ANDROID CAPABILITY

WIND RIVER SECURE ANDROID CAPABILITY WIND RIVER SECURE ANDROID CAPABILITY Cyber warfare has swiftly migrated from hacking into enterprise networks and the Internet to targeting, and being triggered from, mobile devices. With the recent explosion

More information

Cryptographic Modules, Security Level Enhanced. Endorsed by the Bundesamt für Sicherheit in der Informationstechnik

Cryptographic Modules, Security Level Enhanced. Endorsed by the Bundesamt für Sicherheit in der Informationstechnik Common Criteria Protection Profile Cryptographic Modules, Security Level Enhanced BSI-CC-PP-0045 Endorsed by the Foreword This Protection Profile - Cryptographic Modules, Security Level Enhanced - is issued

More information

Information Security Office. Logging Standard

Information Security Office. Logging Standard Information Security Office Logging Standard Revision History Revision Revised By Summary of Revisions Section(s) / Date Page(s) Revised 6/01/2013 ISO Initial Release All Approvals Review Date Reviewed

More information

North American Electric Reliability Corporation: Critical Infrastructure Protection, Version 5 (NERC-CIP V5)

North American Electric Reliability Corporation: Critical Infrastructure Protection, Version 5 (NERC-CIP V5) Whitepaper North American Electric Reliability Corporation: Critical Infrastructure Protection, Version 5 (NERC-CIP V5) NERC-CIP Overview The North American Electric Reliability Corporation (NERC) is a

More information

USB Portable Storage Device: Security Problem Definition Summary

USB Portable Storage Device: Security Problem Definition Summary USB Portable Storage Device: Security Problem Definition Summary Introduction The USB Portable Storage Device (hereafter referred to as the device or the TOE ) is a portable storage device that provides

More information

CYBERSECURITY TESTING & CERTIFICATION SERVICE TERMS

CYBERSECURITY TESTING & CERTIFICATION SERVICE TERMS CYBERSECURITY TESTING & CERTIFICATION SERVICE TERMS These Cybersecurity Testing and Certification Service Terms ( Service Terms ) shall govern the provision of cybersecurity testing and certification services

More information

Information Security Policies. Version 6.1

Information Security Policies. Version 6.1 Information Security Policies Version 6.1 Information Security Policies Contents: 1. Information Security page 3 2. Business Continuity page 5 3. Compliance page 6 4. Outsourcing and Third Party Access

More information

VICTORIA UNIVERSITY OF WELLINGTON Te Whare Wānanga o te Ūpoko o te Ika a Māui

VICTORIA UNIVERSITY OF WELLINGTON Te Whare Wānanga o te Ūpoko o te Ika a Māui VICTORIA UNIVERSITY OF WELLINGTON Te Whare Wānanga o te Ūpoko o te Ika a Māui School of Engineering and Computer Science Te Kura Mātai Pūkaha, Pūrorohiko PO Box 600 Wellington New Zealand Tel: +64 4 463

More information

CMSC 421, Operating Systems. Fall 2008. Security. URL: http://www.csee.umbc.edu/~kalpakis/courses/421. Dr. Kalpakis

CMSC 421, Operating Systems. Fall 2008. Security. URL: http://www.csee.umbc.edu/~kalpakis/courses/421. Dr. Kalpakis CMSC 421, Operating Systems. Fall 2008 Security Dr. Kalpakis URL: http://www.csee.umbc.edu/~kalpakis/courses/421 Outline The Security Problem Authentication Program Threats System Threats Securing Systems

More information

Complying with PCI Data Security

Complying with PCI Data Security Complying with PCI Data Security Solution BRIEF Retailers, financial institutions, data processors, and any other vendors that manage credit card holder data today must adhere to strict policies for ensuring

More information

USB Portable Storage Device: Security Problem Definition Summary

USB Portable Storage Device: Security Problem Definition Summary USB Portable Storage Device: Security Problem Definition Summary Introduction The USB Portable Storage Device (hereafter referred to as the device or the TOE ) is a portable storage device that provides

More information

Chap. 1: Introduction

Chap. 1: Introduction Chap. 1: Introduction Introduction Services, Mechanisms, and Attacks The OSI Security Architecture Cryptography 1 1 Introduction Computer Security the generic name for the collection of tools designed

More information

Host Hardening. Presented by. Douglas Couch & Nathan Heck Security Analysts for ITaP 1

Host Hardening. Presented by. Douglas Couch & Nathan Heck Security Analysts for ITaP 1 Host Hardening Presented by Douglas Couch & Nathan Heck Security Analysts for ITaP 1 Background National Institute of Standards and Technology Draft Guide to General Server Security SP800-123 Server A

More information

NIST 800-53A: Guide for Assessing the Security Controls in Federal Information Systems. Samuel R. Ashmore Margarita Castillo Barry Gavrich

NIST 800-53A: Guide for Assessing the Security Controls in Federal Information Systems. Samuel R. Ashmore Margarita Castillo Barry Gavrich NIST 800-53A: Guide for Assessing the Security Controls in Federal Information Systems Samuel R. Ashmore Margarita Castillo Barry Gavrich CS589 Information & Risk Management New Mexico Tech Spring 2007

More information

CPA SECURITY CHARACTERISTIC ENTERPRISE MANAGEMENT OF DATA AT REST ENCRYPTION

CPA SECURITY CHARACTERISTIC ENTERPRISE MANAGEMENT OF DATA AT REST ENCRYPTION UNCLASSIFIED 24426399 CPA SECURITY CHARACTERISTIC ENTERPRISE MANAGEMENT OF DATA AT REST ENCRYPTION Version 1.0 Crown Copyright 2013 All Rights Reserved UNCLASSIFIED Page 1 UNCLASSIFIED Enterprise Management

More information

SCADA Compliance Tools For NERC-CIP. The Right Tools for Bringing Your Organization in Line with the Latest Standards

SCADA Compliance Tools For NERC-CIP. The Right Tools for Bringing Your Organization in Line with the Latest Standards SCADA Compliance Tools For NERC-CIP The Right Tools for Bringing Your Organization in Line with the Latest Standards OVERVIEW Electrical utilities are responsible for defining critical cyber assets which

More information

Application Intrusion Detection

Application Intrusion Detection Application Intrusion Detection Drew Miller Black Hat Consulting Application Intrusion Detection Introduction Mitigating Exposures Monitoring Exposures Response Times Proactive Risk Analysis Summary Introduction

More information

a) Encryption is enabled on the access point. b) The conference room network is on a separate virtual local area network (VLAN)

a) Encryption is enabled on the access point. b) The conference room network is on a separate virtual local area network (VLAN) MIS5206 Week 12 Your Name Date 1. Which significant risk is introduced by running the file transfer protocol (FTP) service on a server in a demilitarized zone (DMZ)? a) User from within could send a file

More information

Newcastle University Information Security Procedures Version 3

Newcastle University Information Security Procedures Version 3 Newcastle University Information Security Procedures Version 3 A Information Security Procedures 2 B Business Continuity 3 C Compliance 4 D Outsourcing and Third Party Access 5 E Personnel 6 F Operations

More information

Potential Targets - Field Devices

Potential Targets - Field Devices Potential Targets - Field Devices Motorola Field Devices: Remote Terminal Units ACE 3600 Front End Devices ACE IP Gateway ACE Field Interface Unit (ACE FIU) 2 Credential Cracking Repeated attempts to

More information

Payment Card Industry (PCI) Terminal Software Security. Best Practices

Payment Card Industry (PCI) Terminal Software Security. Best Practices Payment Card Industry (PCI) Terminal Software Security Best Version 1.0 December 2014 Document Changes Date Version Description June 2014 Draft Initial July 23, 2014 Core Redesign for core and other August

More information

Security Implications Associated with Mass Notification Systems

Security Implications Associated with Mass Notification Systems Security Implications Associated with Mass Notification Systems Overview Cyber infrastructure: Includes electronic information and communications systems and services and the information contained in these

More information

FISMA / NIST 800-53 REVISION 3 COMPLIANCE

FISMA / NIST 800-53 REVISION 3 COMPLIANCE Mandated by the Federal Information Security Management Act (FISMA) of 2002, the National Institute of Standards and Technology (NIST) created special publication 800-53 to provide guidelines on security

More information

Credit Card Security

Credit Card Security Credit Card Security Created 16 Apr 2014 Revised 16 Apr 2014 Reviewed 16 Apr 2014 Purpose This policy is intended to ensure customer personal information, particularly credit card information and primary

More information

Sample CDC Certification and Accreditation Checklist For an Application That Is Considered a Moderate Threat

Sample CDC Certification and Accreditation Checklist For an Application That Is Considered a Moderate Threat Sample CDC Certification and Accreditation Checklist For an Application That Is Considered a Moderate Threat Centers for Disease and Prevention National Center for Chronic Disease Prevention and Health

More information

Security Standard: Servers, Server-based Applications and Databases

Security Standard: Servers, Server-based Applications and Databases Security Standard: Servers, Server-based Applications and Databases Scope This standard applies to all servers (including production, training, test, and development servers) and the operating system,

More information

Certification Report

Certification Report Certification Report EAL 4+ Evaluation of ncipher nshield Family of Hardware Security Modules Firmware Version 2.33.60 Issued by: Communications Security Establishment Canada Certification Body Canadian

More information

8070.S000 Application Security

8070.S000 Application Security 8070.S000 Application Security Last Revised: 02/26/15 Final 02/26/15 REVISION CONTROL Document Title: Author: File Reference: Application Security Information Security 8070.S000_Application_Security.docx

More information

Threat Modeling. Frank Piessens (Frank.Piessens@cs.kuleuven.be ) KATHOLIEKE UNIVERSITEIT LEUVEN

Threat Modeling. Frank Piessens (Frank.Piessens@cs.kuleuven.be ) KATHOLIEKE UNIVERSITEIT LEUVEN Threat Modeling Frank Piessens (Frank.Piessens@cs.kuleuven.be ) Secappdev 2007 1 Overview Introduction Key Concepts Threats, Vulnerabilities, Countermeasures Example Microsoft s Threat Modeling Process

More information

LogRhythm and PCI Compliance

LogRhythm and PCI Compliance LogRhythm and PCI Compliance The Payment Card Industry (PCI) Data Security Standard (DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent

More information

GE Measurement & Control. Cyber Security for NEI 08-09

GE Measurement & Control. Cyber Security for NEI 08-09 GE Measurement & Control Cyber Security for NEI 08-09 Contents Cyber Security for NEI 08-09...3 Cyber Security Solution Support for NEI 08-09...3 1.0 Access Contols...4 2.0 Audit And Accountability...4

More information

SecureDoc Disk Encryption Cryptographic Engine

SecureDoc Disk Encryption Cryptographic Engine SecureDoc Disk Encryption Cryptographic Engine FIPS 140-2 Non-Proprietary Security Policy Abstract: This document specifies Security Policy enforced by SecureDoc Cryptographic Engine compliant with the

More information

MANAGED FILE TRANSFER: 10 STEPS TO SOX COMPLIANCE

MANAGED FILE TRANSFER: 10 STEPS TO SOX COMPLIANCE WHITE PAPER MANAGED FILE TRANSFER: 10 STEPS TO SOX COMPLIANCE 1. OVERVIEW Do you want to design a file transfer process that is secure? Or one that is compliant? Of course, the answer is both. But it s

More information

Certification Report

Certification Report Certification Report McAfee Network Security Platform v7.1 (M-series sensors) Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria Evaluation and Certification

More information

Information Security Policy September 2009 Newman University IT Services. Information Security Policy

Information Security Policy September 2009 Newman University IT Services. Information Security Policy Contents 1. Statement 1.1 Introduction 1.2 Objectives 1.3 Scope and Policy Structure 1.4 Risk Assessment and Management 1.5 Responsibilities for Information Security 2. Compliance 3. HR Security 3.1 Terms

More information

FINAL DoIT 11.03.2015 - v.4 PAYMENT CARD INDUSTRY DATA SECURITY STANDARDS APPLICATION DEVELOPMENT AND MAINTENANCE PROCEDURES

FINAL DoIT 11.03.2015 - v.4 PAYMENT CARD INDUSTRY DATA SECURITY STANDARDS APPLICATION DEVELOPMENT AND MAINTENANCE PROCEDURES Purpose: The Department of Information Technology (DoIT) is committed to developing secure applications. DoIT s System Development Methodology (SDM) and Application Development requirements ensure that

More information

Thick Client Application Security

Thick Client Application Security Thick Client Application Security Arindam Mandal (arindam.mandal@paladion.net) (http://www.paladion.net) January 2005 This paper discusses the critical vulnerabilities and corresponding risks in a two

More information

Certification Report

Certification Report Certification Report EAL 4 Evaluation of SecureDoc Disk Encryption Version 4.3C Issued by: Communications Security Establishment Certification Body Canadian Common Criteria Evaluation and Certification

More information

Compliance and Industry Regulations

Compliance and Industry Regulations Compliance and Industry Regulations Table of Contents Introduction...1 Executive Summary...1 General Federal Regulations and Oversight Agencies...1 Agency or Industry Specific Regulations...2 Hierarchy

More information

Intrusion Detection and Cyber Security Monitoring of SCADA and DCS Networks

Intrusion Detection and Cyber Security Monitoring of SCADA and DCS Networks Intrusion Detection and Cyber Security Monitoring of SCADA and DCS Networks Dale Peterson Director, Network Security Practice Digital Bond, Inc. 1580 Sawgrass Corporate Parkway, Suite 130 Sunrise, FL 33323

More information

BANKING SECURITY and COMPLIANCE

BANKING SECURITY and COMPLIANCE BANKING SECURITY and COMPLIANCE Cashing In On Banking Security and Compliance With awareness of data breaches at an all-time high, banking institutions are working hard to implement policies and solutions

More information

New Systems and Services Security Guidance

New Systems and Services Security Guidance New Systems and Services Security Guidance Version Version Number Date Author Type of modification / Notes 0.1 29/05/2012 Donna Waymouth First draft 0.2 21/06/2012 Donna Waymouth Update re certificates

More information

Health Insurance Portability and Accountability Act Enterprise Compliance Auditing & Reporting ECAR for HIPAA Technical Product Overview Whitepaper

Health Insurance Portability and Accountability Act Enterprise Compliance Auditing & Reporting ECAR for HIPAA Technical Product Overview Whitepaper Regulatory Compliance Solutions for Microsoft Windows IT Security Controls Supporting DHS HIPAA Final Security Rules Health Insurance Portability and Accountability Act Enterprise Compliance Auditing &

More information

BlackBerry 10.3 Work and Personal Corporate

BlackBerry 10.3 Work and Personal Corporate GOV.UK Guidance BlackBerry 10.3 Work and Personal Corporate Published Contents 1. Usage scenario 2. Summary of platform security 3. How the platform can best satisfy the security recommendations 4. Network

More information

FINAL DoIT 04.01.2013- v.8 APPLICATION SECURITY PROCEDURE

FINAL DoIT 04.01.2013- v.8 APPLICATION SECURITY PROCEDURE Purpose: This procedure identifies what is required to ensure the development of a secure application. Procedure: The five basic areas covered by this document include: Standards for Privacy and Security

More information

Oracle Database Security. Nathan Aaron ICTN 4040 Spring 2006

Oracle Database Security. Nathan Aaron ICTN 4040 Spring 2006 Oracle Database Security Nathan Aaron ICTN 4040 Spring 2006 Introduction It is important to understand the concepts of a database before one can grasp database security. A generic database definition is

More information

Honeywell Industrial Cyber Security Overview and Managed Industrial Cyber Security Services Honeywell Process Solutions (HPS) June 4, 2014

Honeywell Industrial Cyber Security Overview and Managed Industrial Cyber Security Services Honeywell Process Solutions (HPS) June 4, 2014 Industrial Cyber Security Overview and Managed Industrial Cyber Security Services Process Solutions (HPS) June 4, Industrial Cyber Security Industrial Cyber Security is the leading provider of cyber security

More information

Information Security Handbook

Information Security Handbook Information Security Handbook Adopted 6/4/14 Page 0 Page 1 1. Introduction... 5 1.1. Executive Summary... 5 1.2. Governance... 5 1.3. Scope and Application... 5 1.4. Biennial Review... 5 2. Definitions...

More information

UNCLASSIFIED Version 1.0 May 2012

UNCLASSIFIED Version 1.0 May 2012 Secure By Default: Platforms Computing platforms contain vulnerabilities that can be exploited for malicious purposes. Often exploitation does not require a high degree of expertise, as tools and advice

More information

MySQL Security: Best Practices

MySQL Security: Best Practices MySQL Security: Best Practices Sastry Vedantam sastry.vedantam@oracle.com Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes

More information

Data Security Concerns for the Electric Grid

Data Security Concerns for the Electric Grid Data Security Concerns for the Electric Grid Data Security Concerns for the Electric Grid The U.S. power grid infrastructure is a vital component of modern society and commerce, and represents a critical

More information

An Oracle White Paper December 2010. Leveraging Oracle Enterprise Single Sign-On Suite Plus to Achieve HIPAA Compliance

An Oracle White Paper December 2010. Leveraging Oracle Enterprise Single Sign-On Suite Plus to Achieve HIPAA Compliance An Oracle White Paper December 2010 Leveraging Oracle Enterprise Single Sign-On Suite Plus to Achieve HIPAA Compliance Executive Overview... 1 Health Information Portability and Accountability Act Security

More information

Hardware Security Modules for Protecting Embedded Systems

Hardware Security Modules for Protecting Embedded Systems Hardware Security Modules for Protecting Embedded Systems Marko Wolf, ESCRYPT GmbH Embedded Security, Munich, Germany André Weimerskirch, ESCRYPT Inc. Embedded Security, Ann Arbor, USA 1 Introduction &

More information

i-pcgrid Workshop 2015 Cyber Security for Substation Automation The Jagged Line between Utility and Vendors

i-pcgrid Workshop 2015 Cyber Security for Substation Automation The Jagged Line between Utility and Vendors March 25-27, 2014 Steven A. Kunsman i-pcgrid Workshop 2015 Cyber Security for Substation Automation The Jagged Line between Utility and Vendors ABB Inc. March 26, 2015 Slide 1 Cyber Security for Substation

More information

Patch and Vulnerability Management Program

Patch and Vulnerability Management Program Patch and Vulnerability Management Program What is it? A security practice designed to proactively prevent the exploitation of IT vulnerabilities within an organization To reduce the time and money spent

More information

Cryptography and Network Security Sixth Edition by William Stallings

Cryptography and Network Security Sixth Edition by William Stallings Cryptography and Network Security Sixth Edition by William Stallings Chapter 1 Overview The combination of space, time, and strength that must be considered as the basic elements of this theory of defense

More information

A Framework for Secure and Verifiable Logging in Public Communication Networks

A Framework for Secure and Verifiable Logging in Public Communication Networks A Framework for Secure and Verifiable Logging in Public Communication Networks Vassilios Stathopoulos, Panayiotis Kotzanikolaou and Emmanouil Magkos {v.stathopoulos, p.kotzanikolaou}@adae.gr emagos@ionio.gr

More information

Windows Operating Systems. Basic Security

Windows Operating Systems. Basic Security Windows Operating Systems Basic Security Objectives Explain Windows Operating System (OS) common configurations Recognize OS related threats Apply major steps in securing the OS Windows Operating System

More information

BYOD Guidance: BlackBerry Secure Work Space

BYOD Guidance: BlackBerry Secure Work Space GOV.UK Guidance BYOD Guidance: BlackBerry Secure Work Space Published 17 February 2015 Contents 1. About this guidance 2. Summary of key risks 3. Secure Work Space components 4. Technical assessment 5.

More information

7 Network Security. 7.1 Introduction 7.2 Improving the Security 7.3 Internet Security Framework. 7.5 Absolute Security?

7 Network Security. 7.1 Introduction 7.2 Improving the Security 7.3 Internet Security Framework. 7.5 Absolute Security? 7 Network Security 7.1 Introduction 7.2 Improving the Security 7.3 Internet Security Framework 7.4 Firewalls 7.5 Absolute Security? 7.1 Introduction Security of Communications data transport e.g. risk

More information

Data Protection: From PKI to Virtualization & Cloud

Data Protection: From PKI to Virtualization & Cloud Data Protection: From PKI to Virtualization & Cloud Raymond Yeung CISSP, CISA Senior Regional Director, HK/TW, ASEAN & A/NZ SafeNet Inc. Agenda What is PKI? And Value? Traditional PKI Usage Cloud Security

More information

TABLE OF CONTENT. Page 2 of 9 INTERNET FIREWALL POLICY

TABLE OF CONTENT. Page 2 of 9 INTERNET FIREWALL POLICY IT FIREWALL POLICY TABLE OF CONTENT 1. INTRODUCTION... 3 2. TERMS AND DEFINITION... 3 3. PURPOSE... 5 4. SCOPE... 5 5. POLICY STATEMENT... 5 6. REQUIREMENTS... 5 7. OPERATIONS... 6 8. CONFIGURATION...

More information

MCTS Guide to Microsoft Windows 7. Chapter 7 Windows 7 Security Features

MCTS Guide to Microsoft Windows 7. Chapter 7 Windows 7 Security Features MCTS Guide to Microsoft Windows 7 Chapter 7 Windows 7 Security Features Objectives Describe Windows 7 Security Improvements Use the local security policy to secure Windows 7 Enable auditing to record security

More information

Information Security Policy

Information Security Policy Information Security Policy Touro College/University ( Touro ) is committed to information security. Information security is defined as protection of data, applications, networks, and computer systems

More information

Department of Health and Human Services OFFICE OF INSPECTOR GENERAL

Department of Health and Human Services OFFICE OF INSPECTOR GENERAL Department of Health and Human Services OFFICE OF INSPECTOR GENERAL HIGH-RISK SECURITY VULNERABILITIES IDENTIFIED DURING REVIEWS OF INFORMATION SYSTEM GENERAL CONTROLS AT THREE CALIFORNIA MANAGED-CARE

More information

SP 800-130 A Framework for Designing Cryptographic Key Management Systems. 5/25/2012 Lunch and Learn Scott Shorter

SP 800-130 A Framework for Designing Cryptographic Key Management Systems. 5/25/2012 Lunch and Learn Scott Shorter SP 800-130 A Framework for Designing Cryptographic Key Management Systems 5/25/2012 Lunch and Learn Scott Shorter Topics Follows the Sections of SP 800-130 draft 2: Introduction Framework Basics Goals

More information

Information Security Basic Concepts

Information Security Basic Concepts Information Security Basic Concepts 1 What is security in general Security is about protecting assets from damage or harm Focuses on all types of assets Example: your body, possessions, the environment,

More information

Common Criteria Evaluations for the Biometrics Industry

Common Criteria Evaluations for the Biometrics Industry Common Criteria Evaluations for the Biometrics Industry Kathy Malnick Senior Manager Criterian Independent Labs An initiative of the WVHTC Foundation Presentation outline Common Criteria defined Common

More information

Supplier Information Security Addendum for GE Restricted Data

Supplier Information Security Addendum for GE Restricted Data Supplier Information Security Addendum for GE Restricted Data This Supplier Information Security Addendum lists the security controls that GE Suppliers are required to adopt when accessing, processing,

More information

Protection profile of an industrial firewall

Protection profile of an industrial firewall Version 1.0 mid-term GTCSI July 13, 2015 Preface In the whole document, the acronym ToE (Target of Evaluation) designates the component being evaluated. Text in red differs from the short-term version

More information

Supporting FISMA and NIST SP 800-53 with Secure Managed File Transfer

Supporting FISMA and NIST SP 800-53 with Secure Managed File Transfer IPSWITCH FILE TRANSFER WHITE PAPER Supporting FISMA and NIST SP 800-53 with Secure Managed File Transfer www.ipswitchft.com Adherence to United States government security standards can be complex to plan

More information

IS TEST 3 - TIPS FOUR (4) levels of detective controls offered by intrusion detection system (IDS) methodologies. First layer is typically responsible for monitoring the network and network devices. NIDS

More information

Ohio Supercomputer Center

Ohio Supercomputer Center Ohio Supercomputer Center Intrusion Prevention and Detection No: Effective: OSC-12 5/21/09 Issued By: Kevin Wohlever Director of Supercomputer Operations Published By: Ohio Supercomputer Center Original

More information

Introduction to Information Security

Introduction to Information Security Introduction to Information Security Chapter 1 Information Security Basics Winter 2015/2016 Stefan Mangard, www.iaik.tugraz.at What is Information Security? 2 Security vs. Safety The German word Sicherheit

More information

Computer Security: Principles and Practice

Computer Security: Principles and Practice Computer Security: Principles and Practice Chapter 17 IT Security Controls, Plans and Procedures First Edition by William Stallings and Lawrie Brown Lecture slides by Lawrie Brown Implementing IT Security

More information

Securing your Virtual Datacenter. Part 1: Preventing, Mitigating Privilege Escalation

Securing your Virtual Datacenter. Part 1: Preventing, Mitigating Privilege Escalation Securing your Virtual Datacenter Part 1: Preventing, Mitigating Privilege Escalation Before We Start... Today's discussion is by no means an exhaustive discussion of the security implications of virtualization

More information

HIPAA Security COMPLIANCE Checklist For Employers

HIPAA Security COMPLIANCE Checklist For Employers Compliance HIPAA Security COMPLIANCE Checklist For Employers All of the following steps must be completed by April 20, 2006 (April 14, 2005 for Large Health Plans) Broadly speaking, there are three major

More information

Automation Suite for. 201 CMR 17.00 Compliance

Automation Suite for. 201 CMR 17.00 Compliance WHITEPAPER Automation Suite for Assurance with LogRhythm The Massachusetts General Law Chapter 93H regulation 201 CMR 17.00 was enacted on March 1, 2010. The regulation was developed to safeguard personal

More information

Contents. Identity Assurance (Scott Rea Dartmouth College) IdM Workshop, Brisbane Australia, August 19, 2008

Contents. Identity Assurance (Scott Rea Dartmouth College) IdM Workshop, Brisbane Australia, August 19, 2008 Identity Assurance (Scott Rea Dartmouth College) IdM Workshop, Brisbane Australia, August 19, 2008 Contents Authentication and Identity Assurance The Identity Assurance continuum Plain Password Authentication

More information

ICT Professional Optional Programmes

ICT Professional Optional Programmes ICT Professional Optional Programmes Skills Team are a Microsoft Academy with new training rooms and IT labs in our purpose built training centre in Ealing, West London. We offer a range of year-long qualifications

More information

Full Drive Encryption Security Problem Definition - Encryption Engine

Full Drive Encryption Security Problem Definition - Encryption Engine 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 Full Drive Encryption Security Problem Definition - Encryption Engine Introduction for the FDE Collaborative Protection Profiles

More information

Exhibit to Data Center Services Service Component Provider Master Services Agreement

Exhibit to Data Center Services Service Component Provider Master Services Agreement Exhibit to Data Center Services Service Component Provider Master Services Agreement DIR Contract No. DIR-DCS-SCP-MSA-002 Between The State of Texas, acting by and through the Texas Department of Information

More information

SUBJECT: SECURITY OF ELECTRONIC MEDICAL RECORDS COMPLIANCE WITH THE HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996 (HIPAA)

SUBJECT: SECURITY OF ELECTRONIC MEDICAL RECORDS COMPLIANCE WITH THE HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996 (HIPAA) UNIVERSITY OF PITTSBURGH POLICY SUBJECT: SECURITY OF ELECTRONIC MEDICAL RECORDS COMPLIANCE WITH THE HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996 (HIPAA) DATE: March 18, 2005 I. SCOPE This

More information

Audit/Logging Repudiation. Security Testing: Testing for What It s NOT supposed to do

Audit/Logging Repudiation. Security Testing: Testing for What It s NOT supposed to do Audit/Logging Repudiation Laurie Williams williams@csc.ncsu.edu Security Testing: Testing for What It s NOT supposed to do Thompson, Herbert, *, IEEE Security and Privacy, July/Aug 2003, pp. 83-86. 1 Audit

More information

HP ProtectTools Embedded Security Guide

HP ProtectTools Embedded Security Guide HP ProtectTools Embedded Security Guide Document Part Number: 364876-001 May 2004 This guide provides instructions for using the software that allows you to configure settings for the HP ProtectTools Embedded

More information

CrashPlan Security SECURITY CONTEXT TECHNOLOGY

CrashPlan Security SECURITY CONTEXT TECHNOLOGY TECHNICAL SPECIFICATIONS CrashPlan Security CrashPlan is a continuous, multi-destination solution engineered to back up mission-critical data whenever and wherever it is created. Because mobile laptops

More information

HIGH-RISK SECURITY VULNERABILITIES IDENTIFIED DURING REVIEWS OF INFORMATION TECHNOLOGY GENERAL CONTROLS

HIGH-RISK SECURITY VULNERABILITIES IDENTIFIED DURING REVIEWS OF INFORMATION TECHNOLOGY GENERAL CONTROLS Department of Health and Human Services OFFICE OF INSPECTOR GENERAL HIGH-RISK SECURITY VULNERABILITIES IDENTIFIED DURING REVIEWS OF INFORMATION TECHNOLOGY GENERAL CONTROLS AT STATE MEDICAID AGENCIES Inquiries

More information

Achieving PCI COMPLIANCE with the 2020 Audit & Control Suite. www.lepide.com/2020-suite/

Achieving PCI COMPLIANCE with the 2020 Audit & Control Suite. www.lepide.com/2020-suite/ Achieving PCI COMPLIANCE with the 2020 Audit & Control Suite 7. Restrict access to cardholder data by business need to know PCI Article (PCI DSS 3) Report Mapping How we help 7.1 Limit access to system

More information

Content Teaching Academy at James Madison University

Content Teaching Academy at James Madison University Content Teaching Academy at James Madison University 1 2 The Battle Field: Computers, LANs & Internetworks 3 Definitions Computer Security - generic name for the collection of tools designed to protect

More information

Protection profile of an industrial firewall

Protection profile of an industrial firewall Version 1.0 short-term GTCSI July 13, 2015 Preface In the whole document, the acronym ToE (Target of Evaluation) designates the component being evaluated. Text in red differs from the mid-term version

More information

Is Drupal secure? A high-level perspective on web vulnerabilities, Drupal s solutions, and how to maintain site security

Is Drupal secure? A high-level perspective on web vulnerabilities, Drupal s solutions, and how to maintain site security Is Drupal secure? A high-level perspective on web vulnerabilities, Drupal s solutions, and how to maintain site security Presented 2009-05-29 by David Strauss Thinking Securely Security is a process, not

More information

COSC 472 Network Security

COSC 472 Network Security COSC 472 Network Security Instructor: Dr. Enyue (Annie) Lu Office hours: http://faculty.salisbury.edu/~ealu/schedule.htm Office room: HS114 Email: ealu@salisbury.edu Course information: http://faculty.salisbury.edu/~ealu/cosc472/cosc472.html

More information

Columbia University Web Security Standards and Practices. Objective and Scope

Columbia University Web Security Standards and Practices. Objective and Scope Columbia University Web Security Standards and Practices Objective and Scope Effective Date: January 2011 This Web Security Standards and Practices document establishes a baseline of security related requirements

More information

Data Management Policies. Sage ERP Online

Data Management Policies. Sage ERP Online Sage ERP Online Sage ERP Online Table of Contents 1.0 Server Backup and Restore Policy... 3 1.1 Objectives... 3 1.2 Scope... 3 1.3 Responsibilities... 3 1.4 Policy... 4 1.5 Policy Violation... 5 1.6 Communication...

More information