April 19, 2011
Crypto, Encryption, DLP, and Privacy Laws
Doing a project that requires knowledge of international crypto laws. Here is a great resource that has captured information from several sources and put it on a Google map.
How about trying to figure out all those privacy laws for DLP? Here is another map by Simon Hunt for detailing the major international DLP related privacy laws.
Take a look at the DLP map below.
August 7, 2009
BITS Shared Assessments – Useful or Not
What do you think? Is this another useless assessment methodology, great idea, or a platform for vendors to sell products?
I recently went to the 2nd Annual BITs Shared Assessments in Chicago. http://www.sharedassessments.org/
I found the event driven mostly by product vendors, a few assessment firms, and some footprint from the banking industry. During the time of the event and now I was able to deliver an engagement and as a result of the conference and this delivery I have the following comments.
- Many assessors are using older versions of the SIG and still have not adopted 4.2.
- Product vendors have incorporated many of the features and appear to be pushing the solution the most.
- The current AUP and SIG are fairly decent, but the overall solution still needs to mature greatly. I found that several of the AUPs were incorrect or missing. I have yet to consolidate all my comments; however I emailed the main contact number on the site. Currently comments are submitted one by one. I don’t want to enter them one by one, thus, I haven’t submitted as I’m still waiting for a response after several weeks.
- The current scoping and process for delivery is underestimated. My experience shows that you will have to set strict guidelines with the number of follow up conversations and have a cut off for evidence. Otherwise the entity that is assessed will continue to try and justify they have the appropriate controls in place.
- There are plans for mapping to other compliance regulations. There are many more comments I have about this solution, but mostly I’m seeing customers use only the SIG Light or SIG level 2.
I see this as holding a place in the 3rd party assessment realm for an organization. I’m wondering! Is anyone else using the Shared Assessments? What are your thoughts? Will this solution grow and be used like PCI even though it doesn’t have the formal backing like PCI?
March 19, 2009
Do QSA’s Understand PCI?
I guess that title should say “Can anyone clarify PCI?” or “Can we get some PCI consistency please?. I find myself in discussion day after day on topics around PCI.
What is required for web app test? Is it authenticated? Is it just a scan? Is it just my external environment? Is it only my card holder systems?
I know the council is trying to do their best with outlining the standards but their still is a serious lack of consistency across QSA’s and organizations. I found this so frustrating that I developed the cartoon below to represent my opinion.
Basically Mr. CEO here is not meeting PCI compliance and his QSA’s are all telling him something different. Even better is the new standards and enforcement that all the QSA’s themselves are trying to understand? Will any big enterprise be able to make compliance?
January 30, 2009
Authoritative List of Compliance Documents
For anyone looking to find or understand the main key compliance documents across the following industries, regulations, regions of the world the link below has a good list.
http://www.unifiedcompliance.com/matrices/ucf_ad_list.html
Industries, Regulations, Regions:
- Sarbanes Oxley Guidance
- Banking and Finance Guidance
- NASD NYSE Guidance
- Healthcare and Life Science Guidance
- Energy Guidance
- US Federal Security Guidance
- US Internal Revenue Guidance
- Records Management Guidance
- NIST Guidance
- ISO Guidance
- ITIL Guidance
- US Federal Privacy Guidance
- US State Laws Guidance
- EU Guidance
- UK and Canadian Guidance
- Other European and African Guidance
- Asia and Pacific Rim Guidance
- System Configuration Guidance
Also, some of these are already linked off this site. If anyone is feeling like they have some free time feel free to send me links to the listed documents and I will add them to the Links page.
January 12, 2009
Working Toward ISO 17799/27001 Business Continuity Management Compliance
This document is written with the assumption that the organization follows ISO and has implemented many of the controls (including Disaster Recovery), but may be lacking in the area of business continuity management. This document aims to consolidate and leverage the work already done for other ISO controls to jumpstart the BCP compliance efforts.
The first step in compliance is to develop and implement a BCP management process. The process needs to identify the critical business processes within the organization and incorporate management requirements.
Process:
- Identify critical business processes and associated assets. Create a template or leverage the disaster recovery (DR) documentation (Note: The DR information may not be complete enough as it usually only includes recovery of technology functions and may exclude important business functions or process that do not rely on technology.) and send to managers requiring them to document their critical business processes by location.
- Identify the consequences in the event of a disaster. Again most of this should be in a DR plan.
- Identify controls to reduce risk.
- Ensure information for business operations is available.
- Ensure BCP is integrated within business processes and includes security.
- Ensure that plans are updated and tested on a regular basis.
Below is a sample that can be used and quickly put together to help meet some of this compliance. Use Excel and list the critical business processes in a matrix associated with each geographic location as shown below.
The next step is to identity the results of different events by doing a business impact analysis. Continuity plans have to be developed to for quick restoration of operations and should be integrated with information security and other key management processes. Controls that can be put in place to reduce risk should be identified.
The Threat should define “Who”
The Event should define “What, Where, and When”
The table below is an expansion of the above. (Threats are repeated for consistency)
After the assessment the following must be done:
- Continuity plan(s) must be created.
- Roles and responsibilities must be documented. Most should have already been done for other ISO controls, but there may need to be a few short statements added to reflect business continuity compliance.
- Procedures and processes must be documented. Many of these should have already been documented as a part of incident response, disaster recovery, change control, and other standard operations. A few additional procedures may need to be created like the process of documenting and updating plans.
Plans must have the same framework. This means all departmental plans must be a on a standard template. A centralized escalation and evacuation plan should be developed. Evacuation plans can simply state follow building evacuation procedures. Escalation plans in most cases can follow standard disaster, emergency services, or incident response plans.
Plans need to address:
- Roles and responsibilities of key staff (i.e. BCP coordinator, executive management, and users)
- Summary pointing to the documents that have recovery procedures for operations. In many cases these procedures are in the disaster recovery area or part of the standard operating function.
- Testing of plans. This needs to track and schedule each element and when its tested.
- Storage of plans at alternate locations
- Ownership of plans
- Fallback procedures
- Resumption procedures
- Awareness and Training
- Review of plan(s)
Putting everything important together is the key to the business continuity plan. Many of the items above exist within many organizations but they have not been organized or consolidated in one area. A document detailing each of these items and consolidating them all in one location is the key to passing the assessment. If you are already working towards ISO compliance then Business Continuity Management is just one more minor component that can be accomplished quickly by consolidating a large amount of information in one place and creating a document (plan) that organizes and explains everything that needs to be done with these documents if there disruption to business operations. In some cases there may need to be department level plans that are a close mirror to the main plan but focus more on departmental operations. Some assessments will look for both centralized and departmental plans.
For more information you can also review that actual ISO/IEC 17799/27001 documentation and the BS 25999-2 Specification.
September 27, 2007
PHIN 2.0 Requirements
There are updated guides for anyone who does security compliance assessments of works with the Public Health Information Network (PHIN). These were updated in June of 2007. There are many changes from the previous 1.0 version guides. For the new requirements guide see below.
August 3, 2007
BS 31100 Code of Practice for Risk Management
The BS 31100 Code of practice for risk management is also out in draft form free to download and review. This document has the same deadline as the BCM.
BS 25999-2 Business Continuity Management
The BS 25999-2 Specification for business continuity management is out in draft form free to download and review. My apologies for sitting on this so long and not getting it out earlier because the deadline is today for review. Anyway it’s still good to download while you can.
May 25, 2007
ISO 17799 27001 Control or Standard
I recently came across an interesting article explaining the concept of ISO 17799/27001 being a control vs. a standard. This is a good write up because it explains that the ISO documents are there as suggestions and guidance based on a risk assessment.
Many times I talk to organizations that appear to be looking to implement the ISO controls, but there is an education gap. In most cases these organizations are not looking to be compliant for an ISO audit but believe they are increasing the company’s security. If your not looking to be compliant then like all security solutions a risk assessment should be conducted to determine the controls implemented and their priority.
Article:
May 8, 2007
Roles & Responsibilities in Policy
Risk Assessments almost always produce one finding consistently. The finding is lack of roles and responsibilities defined. The ISO 17799/27001 documents provide some guidance, but in many cases organizations do not know how to define clear security roles and responsibilities. Before writing this I went through about 20 different organization policy documents to see if any listed roles and responsibilities the same. In most cases I noticed three solutions.
Solution 1:
This solution did not include clearly define roles and responsibilities. These documents contained few responsibility statements that were scattered through all different areas of the main security policy or policies.
Solution 2:
Solution 2 was the most consistent across all documents reviewed. This solution usually defined three specific roles and responsibilities. These are information owner, information custodian, and information user. Each of these three roles had several statements defining their responsibilities, while there were additional statements scattered through all different sections of the policy document.
Solution 3:
Solution 3 was more consistent on policy documents that are broken up into smaller documents or much shorter in overall length. This solution usually had specific roles such as Firewall Administrator, CSO, System Administrators, Compliance Officer, Audit, etc. In most cases each of these roles had several bulleted responsibilities listed.
What Works?
The best solution is the one that works within your organization and causes less confusion. If risk assessments are performed regularly then make sure the roles and responsibilities are written address the risk assessment requirements. Two methods usually work.
The first is to combine solution 2 and 3 and write a separate roles and responsibilities document or section of the overall policy. This way there are many roles and responsibilities defined, which are easy to find because they are listed all in one place.
The second is to use solution 2 near the beginning (or in a separate policy document) of the policy document then in each different section of the policy (or each smaller policy document) write a roles and responsibilities sub section with more detailed roles.
