1 Improved Event Logging for Security and Forensics: developing audit management infrastructure requirements Atif Ahmad & Anthonie Ruighaver University of Melbourne, Australia Abstract The design and implementation of audit configurations is often constrained by the audit management interface, which typically models operating system structures rather than real world behavior. This paper argues for the need for improved audit management technology as part of an overall top-down approach in the establishment of IT eventlogging policies and practices. We propose that audit management technology should be improved to allow security administrators and forensic investigators to set event log configurations that reflect the security and forensic needs of an organization as defined in security policy. This paper outlines some of the necessary functionality that must be supported by audit management infrastructure in order to facilitate the collection and retention of event data appropriate for different types of real world behaviour. Keywords: Event Logs, Auditing, Security, Forensics, Audit Configuration Introduction In the past, IT security in the corporate environment has often been the responsibility of systems administrators (Neumann, 1989) and, as a result, systems security has been a major focus. Within the context of systems security, audit logs have played an important role since they are the primary source of intrusion related information (Vaccaro, 1989). Hence, audit logs have traditionally been configured by systems administrators independently of corporate security policy, which even if it exists at all generally does not provide adequate guidance in setting up and maintaining security and audit configurations for IT systems. Originally, the main use of audit logs was to monitor performance and to detect intrusions originating from an external source (Anderson, 1980). With the passage of time however, the term intrusion has begun to express a wider meaning closely related to security policy. Security policies have become more comprehensive and frequently include guidelines addressing acceptable behaviour. Any violation of the security policy will now be classified as an intrusion. Although developments in internet connectivity fuel the importance of using audit logs to detect violations of security policy and, more recently, to collect forensic data to support security objectives (Sommer, 1997), in practice event logging is often poorly configured or not configured at all (PWC, 2002). Audit configuration has, until now, mainly been a bottom-up process. Audit management tools have unfortunately constrained the design and implementation of audit configurations due to their modelling of operating system structures rather than real world behaviour. We propose that audit management technology should be improved to
2 allow security administrators and forensic investigators to set event log configurations that reflect the security and forensic needs of an organization as defined in security policy. This approach ensures that audit configuration across the organization will be consistent to some degree, and supports the organization s security objectives. This paper begins by referring to a gap between stated objectives of organizational security policy and audit configuration of event logs which we reported in a previous paper (Ahmad, 2002). We briefly discuss the top-down approach we proposed to bridge this gap and will then identify the limitations imposed upon administrators by the audit management infrastructure currently available in most Operating Systems. Finally we will detail the main issues in the planning of event data collection and its subsequent management. A Top-Down Approach Towards Improving Audit Management infrastructure Where a corporate security policy exists, there is often a significant gap between the stated objectives of organizational security found in this security policy and the audit configuration of event logs present on systems. Even when the system administrator responsible for the configuration of the audit logs tries to adhere to the relevant objectives of the organization s security policy, the translation of these objectives to a system audit configuration is far from straightforward. The ensuing configuration is frequently inaccurate and incomplete, resulting in insufficient and irrelevant data being collected. To further complicate this process organizations are beginning to require the collection of forensic data for the purposes of litigation. Forensic data collection is the domain of experts; administrators generally do not retain the knowledge necessary to determine which sets of data must be selected to support the need for forensic data collection (Sommer, 1992). Furthermore the process by which data is collected and preserved must meet strict guidelines to be admissible in court. While these guidelines are known to specialists in this field, most administrators are not trained in issues related to the gathering and preservation of forensic data. To reduce the gap between organizational security policy and audit configuration and to align the gathering of audit data with the organizational definition of intrusion, we proposed that organizations should develop an organization wide high-level audit policy (Ahmad, 2002). This document will set mandatory audit directives that support the organization s security objectives and ensure that the security of systems will reflect the needs of the organization as defined in the security policy. These directives must stipulate the gathering of data for intrusion detection and/or forensic purposes (fig 1). Other organizational needs, like the collection of data for performance monitoring, may also be included in the audit policy. The aim of such a document is to provide administrators with a defined audit policy that can then be used to design audit configurations for various IT platforms, thereby maintaining consistency across the IT domain.
3 Figure 1: Top-Down approach towards translating security policy to event log configuration The content and structure of the high-level audit policy will obviously not only depend on the organizational goals and objectives identified in the audit policy development process, but also on the capabilities and functionality of the Audit Management Interface. As we will discuss in the next section, the current audit configuration interfaces and tools available in both the Unix and Windows operating systems are severely limiting the translation of audit policy objectives into a high-quality audit configuration. This forces the audit policy development process to take into account many low-level issues, making this process more complicated and costly as well. The Need for an improved Audit Management Interface The process of enforcing organizational policy objectives involves deciding upon a number of issues regarding the behaviour of users and systems in the corporate IT environment. For example, precisely what kinds of user behaviour must be audited? What kinds of real world events violate security policy? Once a comprehensive set of security policy violations is described, administrators can then configure systems to enable their detection. The ability of an administrator to configure event logs on IT systems to identify security policy violations often relies upon the auditing interface and its underlying functionality provided by operating systems. These facilities are typically unable to efficiently map real world events to entries in the audit log. Instead, administrators are presented with a collection of switches representing operating system actions upon operating system objects. Hence administrators find themselves changing perspective to the complex and mechanical view of an operating system. Arising from the operating system view is a distinctly different set of questions such as what subjects, objects and actions must be audited? How much data is enough? How long must the data be kept? What protection
4 mechanisms must be in place to prevent availability, integrity, and confidentiality attacks? Auditing user behaviour is made even more complex because not all the actions executed by a user-initiated process may be according to the user s intention. Operating systems view activity in terms of three elements, subjects, objects and the actions initiated by subjects on objects (Denning, 1986). For example a process may have been created upon the direct instruction of a real world user and subsequently a number of actions may be executed before the process is terminated. From the view of the operating system the process (in this case the subject) is responsible for all actions committed. However, users frequently initiate processes whose subsequent actions are dictated by pre-arranged instructions (scripts, dlls, etc) written by third parties. These actions may or may not be in accordance with the intentions of the user when he/she initiated the process. It is therefore difficult to distinguish between operating system actions that are intended by the user and those that are not. Understanding user behaviour is even more difficult when there is no direct support in the operating system for the logging of user input events. Hence, when forced to view real world actions from the perspective of an operating system, investigators often find it difficult to identify a user s intentions. Separating user intentions from system behaviour can be improved by collecting additional sets of audit data that links users to the actions they are directly responsible for. However, the precise audit configuration required to achieve this goal may be too complex for most administrators to conveniently design and implement without a well-designed high-level audit management interface. To assist administrators in translating high level audit policy to audit configuration, operating systems must have an audit management interface that allows administrators to select suggested sets of audit data appropriate for certain types of real world behaviour via an easy to use management interface. High-level audit policies that incorporate intrusion detection must identify the types of behaviour that are considered intrusive or in violation of security policy directives. For example users running a certain combination of network applications at the same time or in sequence to access particular Internet sites may be violating security policy directives. Audit data collection for such types of behaviour may incorporate forensic as well as security elements. The precise set of data that must be collected is not easily determinable. Frequently administrators are unsure of what audit configuration to set and end up collecting considerable amounts of event data during the period when suspected users are expected to be exhibiting anomalous behaviour. Post-incident analysis becomes a time consuming activity after which the logs often reveal that a small percentage of relevant data was collected. A useful audit management interface needs to assist administrators in controlling the type and amount of data they would like to record relating to real world events. The audit management interface must present the administrator with models of typical user behaviour often identified by audit policies as intrusive and suggest associated audit configurations. For example, the installation of software by a user may be a breach of the security policy. An audit management interface should allow administrators to select
5 Log software installation. As a result, the underlying event management infrastructure will be configured to collect at least the minimum acceptable amount ( base-line) of event information which satisfies security and forensic requirements: Log username, date/time, copy of executable, workstation id, path ON (minimum recommended status) Registry Action Log any changes to HKEY_LOCAL_MACHINE only Log any changes to CURRENT_USERS Log all changes to the registry File Server Action Log any changes to the system directory Log any changes to the file system. Status ON (minimum recommended status) OFF OFF ON (minimum recommended status) OFF Table 1: Sample base-line event logging for the violation Attempt to Install Software Hence, at a minimum, selecting Log software installation will include the logging of the username, current date/time, workstation id. And any changes to the HKEY_LOCAL_MACHINE key of the registry and the system directory. Additional recommended options by security and forensics experts may be provided to facilitate additional event logging. Issues to be Addressed by An Improved Audit Management infrastructure Having extensively argued in the previous sections on the need for an improved Audit Management Interface, we will now discuss some of the functionality and requirements for such an interface. As shown in figure 2, we will discuss what is needed to support the selection of event data, the possible reduction of redundancy in this event data, what needs to be done to secure the event logs and finally how to manage the storage and retention of event logs. Figure 2: Audit management functionality
6 Planning Event Collection The collection of event data to log is the central issue facing administrators. Event data must reflect security and forensics guidelines and must detect and deter violations as well as providing evidence for forensic use. In the past administrators have exhibited a tendency to simply configure event-logging technology to record what might possibly be useful, without considering precisely what event data was needed as defined by security and forensic objectives. Correct planning of event collection is more than just configuring the existing eventlogging interface in the operating system. Frequently the set of event data that must be collected to meet each of the aforementioned requirements cannot be recorded by existing technology provided with the audit domain. In such a case administrators must implement additional gathering mechanisms to attempt to satisfy security and forensic requirements (figure 3). Figure 3: Possible events generated by a computer system in a networked environment There are a number of issues that relate to the collection of a minimum set of audit data that fulfils stated objectives (figure 4). For example, audit events may not provide sufficient context without related files (Schaen, 1991). Audit events may lack sufficient detail needed to provide a vivid picture of what may have happened, and the logs may not identify the real world incident in any useful way (Sommer, 1998). Recording that a file was modified by an unauthorized user at a particular date and time is useful however without preserving the before and after versions of the file it may be difficult to determine what the user was attempting to do to the content of the file. Event data collection requires determining where in the operating system and network audit data may be found and when it is accessible. It is necessary for event data collectors to ensure that such data is not easy to manipulate within the operating system and that the data is securely retrieved into the audit log.
7 In general, the kinds of data that must be logged for each event are mentioned below (ACSP, 1998): Time and date of activities User ID ID of local terminal or remote computer System job number/process number Error conditions like failed attempts at executing a task Reducing Event Data Figure 4: Event data acquisition environment The increasing size of hard disks and the decreasing cost of data storage have removed one of the main limitations of event logging. There is no real reason anymore to limit the size of the event logs and operating system performance should be the only remaining consideration in deciding how much event data should be generated. Future eventlogging technologies can exploit this new situation and attempt to reduce overheads in the event-logging processes by applying more intelligence at the point where event data is generated. An example would be to allow the event logging procedure to make the final decision on whether a certain event needs to be logged based on either simple heuristics or based on the current panic level of the operating system. With the main limitation on the size of event logs removed, the argument for audit reduction now focuses on the capacity of security and forensic personnel to read and make sense of lengthy audit logs. The execution of a single real-world action will frequently result in the recording of multiple sets of similar log records, which on further investigation may prove to be uninteresting and/or irrelevant. However, any changes in the pattern of these sets of log entries would definitely be of interest to an investigator and simply not recording these similar sets at all is definitely not acceptable
8 It may be possible to reduce the redundancy of an event log by analysing the generated audit records. The aim would be to combine several related events into a single new event that identifies particular real world behaviour in a meaningful way. This technique of replacing multiple log records that pertain to a single real world action is a useful way of increasing comprehension and reducing volume simultaneously. However it may be difficult to prove such processes to be forensically neutral (Sommer, 1998). It may also be difficult to demonstrate that the integrity of such reduction (and expansion) remains consistently sound. Security Audit management infrastructure must address the confidentiality, integrity and availability of audit data to the organization (Schaen, 1991). Access control, encryption and other controls may need to be enforced on collected audit data to prevent unauthorized access. Event data progress through a lifecycle starting from the time of collection to time of retirement. During this timeframe the confidentiality, integrity and availability of the event data must be maintained regardless of the environment where it is kept. Whether it is stored in a part of the operating system, whether it has been integrated into a centralized database, or whether it is in transit to a court where it is to be presented. Operating systems typically rely on rudimentary access control mechanisms to protect event logs. Encryption may be used to protect the integrity of the event logs starting from the point of event collection (Schneier, 1999). Issues regarding the security classification of audit data existing at varying degrees of sensitivity must also be addressed. In addition, logs may be related to each other based on the context in which they were recorded. Security classification must take into account the possibility that one log may contain information that may be relevant (and revealing) to another log of a higher sensitivity rating. As a minimum audit management technology must include: Access control requirements on audit trails (Confidentiality, Integrity) Organizational procedures on obtaining access to audit trails and setting up sensitivity rating along with contextual relationships Storage and Retention of Event Data The Audit Management Infrastructure must provide controls to regulate minimum retention periods for sets of audit data. In addition, the possibility that the elimination of one set of audit data may affect the usefulness of another must also be taken into consideration. Storage of audit logs must also be controlled as in whether logs should be stored locally or in a centralized location. Separation between security levels of data must be taken into
9 account as well as the impact of encryption on consolidation. Backup media itself must be protected and disposed off securely when retired (Schaen, 1991). The statement below is a catch-all phrase that is frequently used in security policies to control the use of backup media, but it s presence may not be sufficient to ensure that security administrators apply the same guidelines to audit data (ISP, 1997). All backup media will be stored in a safe, secure environment, in accordance with the manufacturer s specifications. Media which has been used to store sensitive data will be disposed of securely and safely when no longer required. Audit infrastructure must control: The precise storage environment where audit data must be kept Whether audit data will be stored in a centralized location or distributed location Conclusion Traditionally, administrators have been responsible for the implementation of audit configurations on IT systems that support security directives established by the organization. However, frequently organizational security policies do not normally incorporate clear audit directives. This leaves the administrator with the task of interpreting security directives and using them to formulate system audit configurations. In addition operating systems constrain administrators when auditing intrusive behaviour that violates the security directives specified in organizational security policy. Operating systems view real world events from the perspective of its inner workings. Administrators are therefore forced to view user behaviour in terms of operating system subjects, objects and actions. The result of which is frequently an inadequate audit configuration that does not reflect the security policy set out by management. To bridge this gap, the audit management interface to an operating system needs to allow administrators to select appropriate sets of audit data targeting the types of user behaviour considered intrusive by high-level audit policies. The collection of event data to log is the central issue facing administrators. Event data must reflect security and forensics guidelines that must be observed when collection is planned and event data is subsequently managed. A number of issues have been discussed pertaining to the selection, reduction, security, storage and retention of event data. Of these, support for planning, support for retention, and improved security must be taken into consideration when designing improved audit management infrastructure for security and forensic use.
10 References Ahmad, A., and Ruighaver, T. (2002), A Top-Down Approach Towards Translating Organizational Security Policy Directives to System Audit Configuration, Proceedings of the 17 th IFIP TC 11 International Conference on Information Security, Cairo, Egypt, 7-9 May, Anderson, J. P. (1980), Computer Security threat monitoring and surveillance. Technical Report. James P. Anderson Co., Fort Washington, PA, April Denning, Dorothy (1986), An Intrusion-Detection Model, IEEE Computer Society Symposium on Research in Security and Privacy, pp ISP (1997), Information Security Policy, University of New South Wales, P. W. C. (2002), Information Security Breaches Survey 2002, Technical Report, Price Waterhouse Coopers, 2002 Neumann, P., Parker, D. (1989), A Summary of Computer Misuse Techniques, Proceedings of the 12 th National Computer Security Conference, Baltimore, Maryland, October, Schaen, S., I.,McKenney, B.W. (1991), Network Auditing: Issues and Recommendations. IEEE: Schneier B. and Kelsey J., Secure Audit Logs to Support Computer Forensics, ACM Transactions on Information and System Security, v. 2, n. 2, May 1999, pp Sommer, P. (1992), Computer Forensics: an Introduction, Compsec '92, Elsevier, Sommer, P. (1997), Downloads, Logs and Captures: Evidence from Cyberspace, Journal of Financial Crime, October, 1997, 5JFC ; Vaccaro, H.S., Liepins, G. E. (1989), Detection of anomalous computer session activity, In 1989 IEEE Symposium on Security and Privacy, pages , Oakland, CA, USA, May IEEE Piscataway NJ USA. Wee, C. (1996), Policy Directed Auditing and Logging, PhD Thesis, UC Davis, Dept. of Comp. Science, 1996.
1 The Forensic Chain-of-Evidence Model: Improving the Process of Evidence Collection in Incident Handling Procedures Atif Ahmad Department of Information Systems, University of Melbourne, Parkville, VIC
Design of a Network-Access Audit Log for Security Monitoring and Forensic Investigation Atif Ahmad Tobias Ruighaver University of Melbourne Department of Information Systems, University of Melbourne, Parkville,
Supplier Instructions for Processing of Personal Data 1 PURPOSE SOS International has legal and contractual obligations on the matters of data protection and IT security. As a part of these obligations
Acquire or develop application systems software Controls provide reasonable assurance that application and system software is acquired or developed that effectively supports financial reporting requirements.
Unified Security Reduce the Cost of Compliance Introduction In an effort to achieve a consistent and reliable security program, many organizations have adopted the standard as a key compliance strategy
ITP Number ITP-SEC024 Category Security Contact RA-ITCentral@pa.gov Information Technology Policy IT Security Incident Policy Effective Date August 2, 2012 Supersedes Scheduled Review Annual 1. Purpose
Solution Brief for ISO 27002: 2013 Audit Standard Publication Date: Feb 6, 2015 8815 Centre Park Drive, Columbia MD 21045 ISO 27002 About delivers business critical software and services that transform
Enterprise Forensics and ediscovery (EnCase) Privacy Impact Assessment PIA Approval Date Mar. 14, 2011 System Overview The Enterprise Forensics and ediscovery (EnCase) solution is a major application that
ISO 27001 COMPLIANCE WITH OBSERVEIT OVERVIEW ISO/IEC 27001 is a framework of policies and procedures that include all legal, physical and technical controls involved in an organization s information risk
NIST CYBERSECURITY FRAMEWORK COMPLIANCE WITH OBSERVEIT OVERVIEW The National Institute of Standards of Technology Framework for Improving Critical Infrastructure Cybersecurity (The NIST Framework) is a
Intrusion Detection Marlicia J. Pollard East Carolina University ICTN 4040 SECTION 602 Mrs. Boahn Dr. Lunsford For this term paper I will be discussing the subject of Intrusion detection. I will be going
Network Security: Policies and Guidelines for Effective Network Management Department of Electrical and Computer Engineering, Federal University of Technology, Minna, Nigeria. firstname.lastname@example.org, email@example.com
LAMAR STATE COLLEGE - ORANGE INFORMATION RESOURCES SECURITY MANUAL for INFORMATION RESOURCES Updated: June 2007 Information Resources Security Manual 1. Purpose of Security Manual 2. Audience 3. Acceptable
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
IBX Business Network Platform Information Security Controls 2015-02- 20 Document Classification [Public] Table of Contents 1. General 2 2. Physical Security 2 3. Network Access Control 2 4. Operating System
Office of the Auditor General Performance Audit Report Statewide UNIX Security Controls Department of Technology, Management, and Budget December 2015 State of Michigan Auditor General Doug A. Ringler,
Information Security Policy Chapter 10 Information Security Incident Management Policy Author: Policy & Strategy Team Version: 0.4 Date: December 2007 Version 0.4 Page 1 of 6 Document Control Information
Overview This policy sets out the requirements expected of third parties to effectively protect BBC information. Audience Owner Contacts This policy applies to all third parties and staff, including contractors,
FINAL May 2005 Guideline on Security Systems for Safeguarding Customer Information Table of Contents 1 Introduction 1 1.1 Purpose of Guideline 1 2 Definitions 2 3 Internal Controls and Procedures 2 3.1
IT OUTSOURCING SECURITY February 2008 The Government of the Hong Kong Special Administrative Region The contents of this document remain the property of, and may not be reproduced in whole or in part without
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
RSA Solution Brief Streamlining Security Operations with Managing RSA the Lifecycle of Data Loss Prevention and Encryption RSA envision Keys with Solutions RSA Key Manager RSA Solution Brief 1 Who is asking
Information Systems Security Policy University of South Alabama Computer Services Center University of South Alabama 5840 USA Drive South 251-460- 6161 5/19/2014 Outline 1 Introduction... 2 Data Retrieval
Sarbanes-Oxley Control Transformation Through Automation An Executive White Paper By BLUE LANCE, Inc. Where have we been? Where are we going? BLUE LANCE INC. www.bluelance.com 713.255.4800 firstname.lastname@example.org
Appendix Key Areas of Concern i. Inadequate coverage of cybersecurity risk assessment exercises The scope coverage of cybersecurity risk assessment exercises, such as cybersecurity control gap analysis
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
PRODUCT BRIEF LOG AND EVENT MANAGEMENT FOR SECURITY AND COMPLIANCE The Tripwire VIA platform delivers system state intelligence, a continuous approach to security that provides leading indicators of breach
Information Technology Security Review April 16, 2012 The Office of the City Auditor conducted this project in accordance with the International Standards for the Professional Practice of Internal Auditing
Cloud Computing Security Considerations Roger Halbheer, Chief Security Advisor, Public Sector, EMEA Doug Cavit, Principal Security Strategist Lead, Trustworthy Computing, USA January 2010 1 Introduction
Security Controls What Works Southside Virginia Community College: Security Awareness Session Overview Identification of Information Security Drivers Identification of Regulations and Acts Introduction
CMSGu2012-05 Mauritian Computer Emergency Response Team CERT-MU SECURITY GUIDELINE 2011-02 Enhancing Cyber Security in Mauritius Guideline on Auditing and Log Management National Computer Board Mauritius
PRODUCT BRIEF LOG MANAGEMENT AND SIEM FOR SECURITY AND COMPLIANCE As part of the Tripwire VIA platform, Tripwire Log Center offers out-of-the-box integration with Tripwire Enterprise to offer visibility
elearning Course Outlines IT Networking and Security powered by Calibrate elearning Course Outline CompTIA A+ 801: Fundamentals of Computer Hardware/Software www.medallionlearning.com Fundamentals of Computer
Cybersecurity Framework Security Policy Mapping Table The following table illustrates how specific requirements of the US Cybersecurity Framework  are addressed by the ISO 27002 standard and covered
Regulatory Compliance Solutions for Microsoft Windows IT Security Controls Supporting DHS HIPAA Final Security Rules Health Insurance Portability and Accountability Act Enterprise Compliance Auditing &
OFFICE OF THE CHIEF INFORMATION OFFICER Date of Issuance: May 22, 2009 Effective Date: May 22, 2009 Review Date: Section I. PURPOSE II. AUTHORITY III. SCOPE IV. DEFINITIONS V. POLICY VI. RESPONSIBILITIES
Corporate Incident Response Why You Can t Afford to Ignore It Whether your company needs to comply with new legislation, defend against financial loss, protect its corporate reputation or a combination
SCP.03.00.EN.1.0 Table of contents Table of contents... 2 1 Introduction... 3 1.1 Spillemyndigheden s certification programme... 3 1.2 Objectives of the... 3 1.3 Scope of this document... 4 1.4 Definitions...
Log Management for the University of California: Issues and Recommendations Table of Contents 1 Introduction...2 2 Candidate Sources of Logged Information...3 3 Recommended Log Management Practices...4
Information Technology Security Policy for IBTS Pakistan Stock Exchange Limited Table of contents Information Technology Security Policy for IBTS 1- INTRODUCTION AND SCOPE... 3 2- CHARTER OF THE DOCUMENT...
Network Security Forensics As hacking and security threats grow in complexity and organizations face stringent requirements to document access to private data on the network, organizations require a new
IT Best Practices Audit TCS offers a wide range of IT Best Practices Audit content covering 15 subjects and over 2200 topics, including: 1. IT Cost Containment 84 topics 2. Cloud Computing Readiness 225
Windows Server Security Best Practices Initial Document Created By: 2009 Windows Server Security Best Practices Committee Document Creation Date: August 21, 2009 Revision Revised By: 2014 Windows Server
T141 Computer Systems Technician MTCU Code 50505 Program Learning Outcomes Synopsis of the Vocational Learning Outcomes * The graduate has reliably demonstrated the ability to 1. analyze and resolve information
Declaration of Conformity 21 CFR Part 11 SIMATIC WinCC flexible 2007 SIEMENS AG Industry Sector Industry Automation D-76181 Karlsruhe, Federal Republic of Germany E-mail: email@example.com Fax: +49
AUDIT OF IT SECURITY Corporate Internal Audit Division Natural Sciences and Engineering Research Council of Canada Social Sciences and Humanities Research Council of Canada September 20, 2012 Corporate
Protecting Official Records as Evidence in the Cloud Environment Anne Thurston Introduction In a cloud computing environment, government records are held in virtual storage. A service provider looks after
INFORMATION SECURITY AND PRIVACY PROTECTION POLICY AND GUIDELINES FOR ESTATE AGENTS Estate Agents Authority The contents of this document remain the property of, and may not be reproduced in whole or in
Sample Information Security Policies Sample Information Security Policies May 31, 2011 1 13740 Research Blvd Suite 2, Building T Austin, TX 78750 512.351.3700 www.aboundresources.com Boston Austin Atlanta
OFFICE OF THE CHIEF INFORMATION OFFICER NETWORK AND AIS AUDIT, LOGGING, AND MONITORING POLICY OCIO-6011-09 Date of Issuance: May 22, 2009 Effective Date: May 22, 2009 Review Date: TABLE OF CONTENTS Section
Sufficiency of Windows Event log as Evidence in Digital Forensics Nurdeen M. Ibrahim & A. Al-Nemrat, Hamid Jahankhani, R. Bashroush University of East London School of Computing, IT and Engineering, UK
Information Security Risk Assessment Checklist A High-Level Tool to Assist USG Institutions with Risk Analysis Updated Oct 2008 Introduction Information security is an important issue for the University
Case Study: Hiring a licensed Security Provider Company Profile McCann Investigations is a full service private investigation firm providing complete case solutions by employing cutting-edge computer forensics
The Office of the Auditor General has conducted a procedural review of the State Data Center (Data Center), a part of the Arizona Strategic Enterprise Technology (ASET) Division within the Arizona Department
Feedback Ferret Security Incident Response Plan Document Reference Feedback Ferret Security Incident Response Plan Version 3.0 Date Created June 2013 Effective From 20 June 2013 Issued By Feedback Ferret
Central Agency for Information Technology Kuwait National IT Governance Framework Information Security Agenda 1 Manage security policy 2 Information security management system procedure Agenda 3 Manage
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
Shipman & Goodwin LLP HIPAA Security Alert July 2008 EXECUTIVE GUIDANCE HIPAA SECURITY COMPLIANCE How would your organization s senior management respond to CMS or OIG inquiries about health information
HALKYN CONSULTING LTD Supplier Security Assessment Questionnaire Security Self-Assessment and Reporting This questionnaire is provided to assist organisations in conducting supplier security assessments.
Technical Standards for Information Security Measures for the Central Government Computer Systems April 21, 2011 Established by the Information Security Policy Council Table of Contents Chapter 2.1 General...
Bring your own device (BYOD) trends and audit considerations SIFMA IT audit session 4 October 2012 Disclaimer Ernst & Young refers to the global organization of member firms of Ernst & Young Global Limited,
Computer Information Systems (Forensics Classes) Objectives for Course Challenges CIS 200 Intro to Info Security: Includes managerial and Describe information security and its critical role in business.
Office of the Chief Information Officer Online File Storage BACKGROUND Online file storage services offer powerful and convenient methods to share files among collaborators, various computers, and mobile
Case Study for XY Bank End-user Security Analytics Strengthens Protection with ArcSight INTRODUCTION Detect and respond to advanced persistent threats (APT) in real-time with Nexthink End-user Security
STATE OF NORTH CAROLINA INFORMATION SYSTEMS AUDIT OFFICE OF INFORMATION TECHNOLOGY SERVICES INFORMATION TECHNOLOGY GENERAL CONTROLS OCTOBER 2014 OFFICE OF THE STATE AUDITOR BETH A. WOOD, CPA STATE AUDITOR
ISO 27001 s and Objectives A.5 Security policy A.5.1 Information security policy Objective: To provide management direction and support for information security in accordance with business requirements
Securing Wireless Networks for PCI Compliance Using Fortinet s Secure WLAN Solution to Meet Regulatory Requirements Introduction In the wake of many well-documented data breaches, standards such as the
MICHIGAN OFFICE OF THE AUDITOR GENERAL AUDIT REPORT THOMAS H. MCTAVISH, C.P.A. AUDITOR GENERAL ...The auditor general shall conduct post audits of financial transactions and accounts of the state and of
SWAP EXECUTION FACILITY OPERATIONAL CAPABILITY TECHNOLOGY QUESTIONNAIRE Please provide all relevant documents responsive to the information requests listed within each area below. In addition to the specific
for the United States Citizenship and Immigration Services (USCIS) June 22, 2007 Contact Point Harry Hopkins Office of Information Technology (OIT) (202) 272-8953 Reviewing Official Hugo Teufel III Chief
SECURITY ORGANISATION Security Awareness and the Five Aspects of Security Shift Security simply used to protect information vs. Enabling business initiatives with security Bolt-on/add-on structure to business
U.S. Department of Energy Office of Inspector General Office of Audits and Inspections AUDIT REPORT The Energy Information Administration s Information Technology Program DOE-OIG-16-04 November 2015 Department
CENTRIFY WHITE PAPER Windows Least Privilege Management and Beyond Abstract Devising an enterprise-wide privilege access scheme for Windows systems is complex (for example, each Window system object has
6 th Floor, Tower A, 1 CyberCity, Ebene, Mauritius T + 230 403 6000 F + 230 403 6060 E ReachUs@abaxservices.com INFORMATION SECURITY POLICY DOCUMENT Information Security Policy Document Page 2 of 15 Introduction
Information Resources Security Guidelines 1. General These guidelines, under the authority of South Texas College Policy #4712- Information Resources Security, set forth the framework for a comprehensive
TECHNICAL AND ORGANIZATIONAL DATA SECURITY MEASURES Contents Introduction... 3 The Technical and Organizational Data Security Measures... 3 Access Control of Processing Areas (Physical)... 3 Access Control
A Proposed Architecture of Intrusion Detection Systems for Internet Banking A B S T R A C T Pritika Mehra Post Graduate Department of Computer Science, Khalsa College for Women Amritsar, India Mehra_priti@yahoo.com
e-governance Password Management Guidelines Draft 0.1 DEPARTMENT OF ELECTRONICS AND INFORMATION TECHNOLOGY Ministry of Communication and Information Technology, Government of India. Document Control S.