The issues and best practices pertaining to information security, management, regulation, compliance and documentary evidence.
“It is not merely good enough to do good you must be seen to be doing good.”
As the above adage highlights the secure management and handling of information is only part of the issue. Being able to prove that you are in deed in full compliance with all relevant regulations and standards is the real crux of the matter.
With the multitude and often duplicity of current laws, regulations and standards, it can be very bewildering just knowing where to start. If you have cross border and jurisdictional transactions, the issues become even cloudier.
Here are some of the issues and best practices pertaining to information security, management and compliance from a documentary evidence perspective.
Logging Requirements
Fortunately, IT does offer a number of options to ease the burden of regulatory compliance and associated creation and management of substantiating evidence. One of the easiest to implement strategies is the development of customized logging procedures, practices and policies.
The beauty with IT logging processes is that for the large part their mechanics are automatable. The reviewing of logs will require some degree of manual involvement. However, log creation and review processes performed in conjunction with data management techniques present us with many filters that are useful in producing a higher degree of granular inspection and control than is possible by manual observation and review alone.
The secret to the effective and efficient use of these procedures lies in both the plan and procedures you develop taking the specifics or your requirements into account and the consistent adherence to the documented review, analysis, response to anomalies, retention and final destruction procedures thereby developed.
Here are a few of the laws, regulations and standards that you may need to take into consideration:
- The US Health Insurance Portability and Accountability Act (HIPAA) along with the US Federal Information Security Management Act (FISMA) are of particular importance here. Others US laws of note in the area of information security include Sarbanes-Oxley (SOX) Act, Gramm-Leach-Bliley Act (GLBA). Various states also have a number of individual breach notice laws that will apply differently in their various jurisdictions.
- Canada’s Personal Information Protection and Electronic Data Act (PIPEDA)
- The EU’s Data Protection Directive along with the European Community Directive Data Privacy Principles (ECDDPP) need evaluating in any assessment(s) undertaken by individual(s) and/or organization(s) currently conducting or hoping to conduct business with organization9s) and/or individual(s), resident or domicile in the EU or jurisdiction thereof
- The Australian Federal Privacy Act (1988) and the subsequent Australian Federal Privacy Act December 2001 Amendments with the provisions pertaining to personally identifiable health related information being of particular note
- The Australian Federal Telecommunications Act 1997, The Australian Federal Corporations Act 2001 and The Australian Federal Spam Act 2003 also merit consideration when developing logging policies pertaining to activities conducted within or with Australian institutions, organizations or individuals
- Local breach notice laws exit in many regional and municipal areas and will therefore need consulting where applicable
- Payment Card Industry (PCI) Data Security Standard (DSS) is a global set of standards more or less adopted by financial institutions and merchants in regards to payment via payment card systems
The Global Perspective
With the multiplicity of these laws, a number of organizations with a more “global” perspective formed to assist with the establishment of greater standards and consistency globally include:
Organisation for Economic Cooperation and Development (OECD) – The OECD is an international organisation that sets policies in areas where multilateral consensus is advantageous for individual countries to make progress in a global economy. The eight basic principles put forth by the OECD are:
- Collection Limitation – Data must be collected lawfully & fairly with subject’s knowledge & consent
- Data Quality – All data collected and retained must be accurate, complete, current, and relevant for its intended use
- Purpose Specification – The purpose for the collection of the data should be specified & remain unchanged
- Use Limitation – Any data collected is not to be used for any purpose other than that originally stated & agreed
- Security Safeguards – Data collected and held must be protected against unauthorised access, modification, or disclosure
- Openness Principle – Data Policies should exist and a data controller should be clearly identified
- Individual Participation – The subject of the data can review, challenge, and enforce correction of their data
- Accountability – The data controller is responsible for ensuring the above principles are met
Other Agencies and Bodies
Other leading privacy agencies and bodies around the world that incorporate the following basic principles, provisions and functionalities either in law or in statue, Opt-out Policy, Opt-in Policy, Additional Personal Privacy Legislation, Wiretaps, Pen Register and Trap and Trace, include:
- Better Business Bureau Online (BBB Online) (USA)
- TRUSTe (USA)
- Communications Assistance for Law Enforcement Agencies (CALEA) (USA)
Resources and Advice
The US National Institute of Standards and Technology (NIST) – NIST are a very good reference source for information and resources involving security, privacy and compliance issues. They have a number (more than 100) free to download special publication dealing with all aspects of information technologies.
One area in which NIST makes public statements is in the area of recommended technologies. NIST will provide indications that certain technologies and standards conform to their recommendations and so will provide advice in terms of supporting or not supporting specific technologies in lieu of superior alternatives.
An example of a technology that NIST once supported but have now withdrawn their support in favor of a replacement technology is in the area of encryption. NIST have now officially withdrawn their support of the 58-bit Digital Encryption Standard (DES) and now recommend Triple DES; also known as Triple Data Encryption Algorithm (TDEA) or the stronger faster Advanced Encryption Standard (AES) algorithm.
Regarding logs and logging procedures and practices the NIST publication NIST 800-92, Guide to Computer Security Log Management is a great resource as it details many ways to establish, evolve and maintain efficient effective log management structures. Topics covered in this publication include log generation, analysis, storage and monitoring. It can be downloaded free of charge from here.
Log Review and Analysis
The reasons as to why you must regularly review and analyze those logs that you record and maintain include regulatory compliance requirements as well as to enhance your information security, privacy and availability overall.
Through persistent, regular, consistent log, review and analysis you will uncover many otherwise undetected activities capable of negatively affecting you or your organization. Some examples of common issues that I regularly find through the log review and audit process include policy violations, application processing errors, fraud, security incidents and operational functionality and efficiency issues.
Policy Development Guidelines
With so many laws and standards having similar requirements regarding logging and log review and analysis procedures a carefully constructed logging plan implemented via a comprehensive log policy that incorporates all of these various elements into a single united logging procedures and practices policy is the best approach to take.
Do not try to satisfy each set of individual regulatory, statutory, or standards requirements piecemeal style. That is, your best plan of attack is to develop a comprehensive policy, which contains a general logging practices and procedures directive and additional specific requirements clauses as supplemental special recommendations on an individual basis for areas that warrant such treatment.
The importance and cost-effectiveness of developing a risk-oriented policy can often be the easiest means to expedite the implementation of procedures and policies where none currently exists or those that do exist are dated or inadequate.
Expediency in the matter of developing, implementing and then further finessing your logging and information control policies is critical in rapidly reducing the potentially negative impacts any immediate exposure to risk factors would cause due to the lack of such a policy.
PCI DSS Compliance
Without doubt, Payment Card Industry (PCI) Data Security Standard (DSS) compliance and ratification (PCI DSS) is the major concern of all who process credit card payments. This sector is of utmost criticality for online business and “offline” transactions alike with “offline” being defined as transactions other than customer initiated Internet-based transaction processing.
In essential requirements for PCI DSS compliance are contained in Section 10 of the PCI DSS standard and detail those actions required (not mandatory) to monitor network activities and cardholder data access events. The best bit here is that the majority of the audit logs generated in compliance with these stipulations also confirm to the requirements of the majority of aspects in this regard required by other laws and regulations.
IMPORTANT TIP – Getting your house in order regarding PCI DSS compliance will have the beneficial side effect of simultaneously fulfilling the majority of the auditing and logging requirements from other areas. Thereby leaving you to custom plug the gaps as your circumstance dictate.
The bean counters love this approach as it addresses their area of immediate concern first – CASH FLOW. Nobody said you have to reveal your full motivations for this approach.
“Work smarter and not just harder” is something my mother always says. Once again, she is right.
PCI DSS Compliance Logging Requirements
Here are some of the computer, network and Internet activities that you will need to log in order to satisfy PCI DSS compliance requirements grouped by activity and class:
Synchronization
Synchronization procedure and mechanisms relating to all computer, system, network and Internet activities need thorough documentation. Not only must time synchronization data accompany all logs it must be included with specificity to every individual itemized event included in the log
Authentication Mechanisms
Current computer, system and network authentication mechanisms need thorough documentation along with additional log information detailing such criteria as changes to authentication mechanisms, invalid authentication events, password changes, administrative authentication-related activities.
Audit Logs
Events requiring documentation and logging here include access to audit logs, any modifications to audit logs and audit logging procedures, the clearing and destruction of audit logs for all components of the network including individual computers, server computers and networking devices as well as the services offered (e.g. Internet).
Cardholder Data
You must thoroughly document cardholder data access, processes, procedures and security initiatives. This includes details of those who are explicitly authorized to access cardholder data and those are not specifically authorized to access to cardholder information. Details concerning the assets and resources involved in these processes must also require inclusion.
Cardholder data related logs must include access to cardholder data events including valid and invalid events along with maintenance and formal audit access events. Other types of cardholder data related events that need logging include cardholder data storage, updating and maintenance, valid and invalid cardholder data applications access events.
System-Level Objects
You must log all system-level object events including creation, deletion, modifications and read-only events. This includes system-level events at the machine-level including workstations and clustered computer resources as well as the datacenter.
Common Network and Cardholder Access Events
All cardholder data access and/or network access events must contain user identifier, event type, event date and time, attempt result (success/failure), event origin, resource identity attributes such as the data file name, system component, computer,network, application, modifications, administrative activities etc.
Log Generation and Management
It is a sad fact that the majority of IT personnel are not cognizant of, nor do they fully understand the issues, implications and ramifications concerning authentication, logging, computers, networking, network monitoring and security logging, accounting and auditing practices.
To compound this further most compliance personal do not have an IT background and often make the fatal assumption that those in IT log everything and retain the logs generated forever. The logistics of this type of approach are unrealistic since the volumes of data generated from a log everything/keep everything approach would rapidly bury an organization.
Another area that different management areas do not fully appreciate is that for the larger part IT must have sufficient appropriate documentation detailing precisely what is required before those requirements are achievable.
Assuming that IT knows all about every other department’s logging requirements is unrealistic. It is essential to inform IT of the logging requirements of other departments if IT is to develop policies appropriate for satisfying organization-wide logging requirements. All logging and reporting activities require resources at the individual computer level as well as the network and organization levels.
A direct result of these factors is that, more times than not, inadequate noncompliant logging procedures and policies become implemented into production environments.
Developing a Log Policy
Here are a few tips to assist you in the development of a log management policy or log management component of your larger log policy.
- General Comprehension – Understand and define the general logging requirements of all sectors of your organization and the types of they logs require. You do not have to fill in all of the nitty-gritty detail at this point.
- Define Specifics – Meet with those responsible for specific areas and discuss in more detail the nature and specifics of their requirements including the types of data and report formats each department needs, the data types that are necessary to achieve organization-wide compliance and the data that each department would require should a breach occur. Discuss matters concerning the feasibility of collecting, collating and storing the logs and reports generated.
- Fiscal Matters – It is best to begin addressing fiscal aspects and concerns now. Without doubt, other departments will be very willing to burden IT with as much of their workload as possible. With IT producing the extra logs and reports in order to satisfy every other department’s requirements it is only reasonable to expect that additional resources may be required.
- Analysis – Analyze these results and determine what areas are common for all. Also, define those areas that are common to most and those that are specific to one or two departments only.
- Evaluate – Examine your current logging procedures and analyze the data types currently collected. Note those aspects of the above requirements you already satisfy. Produce a list of the “missing” factors.
- Plan – Define mechanisms to incorporate collection and collation of these “missing” factors compatible with your system’s current capabilities.
- Test – Implement a trial run. Collect and collate this data then generate the appropriate reports for each department.
- Determine Satisfaction – Meet with the other departments and discuss your trial reports. Determine if these reports are satisfactory. Have the other departments produce a report detailing areas of the trial reports that need amending.
- Amend and Retest – Incorporate the amendments into a new trial run.
- Reevaluate – Repeat the cycle until satisfaction is unanimous with all departments
- Review Regularly – Regularly review your data collection, collation and report generation procedures and policies to ensure complete alignment with all departments concerned.
- Review Currency – Regularly evaluate the currency component of your current logging practices and policies. Make sure the other departments do likewise. Make sure that all departments notify you immediately of any changes to their policy or requirements.
You cannot begin to develop procedures to satisfy another department’s logging requirements if they do not inform you of these changes.
Where Logs Help
Here are some different type of logs and some of the areas in which they are useful.
- Networking Devices Logs – Logs from switches, wireless access points, routers and firewalls can identify intrusion attempts (by hackers for example) as well as connectivity issues such as legitimate authorized users not being able to gain access to assets and resources they are entitled to access.
- Network Access Logs – These logs contain much information concerning network and network metrics as well as authorized and unauthorized access events, which can be very helpful in planning upgrades and network infrastructure changes. You will also find information relating to abuse of privileges and hacking attempts here.
- User Account Logs – User account logs can help in the identification of brute-force password attacks and inappropriate changes in user account privileges.
- Email Logs – Here you will find information that is helpful in the identification of many malicious, unauthorized and undesirable activities. A dramatic increase in inbound email traffic is often the first indicator of an email-based attack. Abnormally large volumes of outbound email traffic can point to a data leakage.
- Application Logs – Will provide information about date, time and identity of client file access. They are a very useful source of information in identifying unauthorized access events as well as fraud and other malicious acts.
Summary
Through a well thought-out and tested network, systems and applications log policy, and the procedures and practices contained within, you will be able to comply with the relevant laws, regulations and standards as well as supporting and improving your organization’s bottom line through early detection of errors, fraud, non-compliance penalties and a host of other negatively impacting events.













Mon, Jun 16, 2008, by TechDoc
Security