On Wednesday, while the virtualization and cloud computing topics were continuing to see a lot of coverage, I began to focus my attendance in some different areas. The first Wednesday keynote included a brief discussion of the 60-day cybersecurity review by Melissa Hathaway, Acting Senior Director for Cyberspace for the Obama administration. While she did not tip her hand regarding what would be in the final report, she spent a lot of time discussing the importance of the report and the work which will come out of it. You can read her speech by following the word document link on this article in The Atlantic.

Also on Wednesday was a panel discussion on the increasing prominence of legal and audit concerns in security featuring two federal judges and two lawyers. The presence of two federal judges at the RSA conference should be viewed as good news, as it clearly demonstrates that the legal system is taking note of and participating in a dialog with the security industry as a whole. Also there was an individual talk in the Governance-Legal track in the same thread, “eDiscovery Cooperation Workshop for Attorneys and Technologists”. Meaningful information security-related laws and regulations can only be developed and enforced by a team which includes the legal system and the security practitioners.

Other sessions that were heavily attended and well regarded were individual sessions for which there is not yet a link for video or audio. These include “Is Google Evil?” by Ira Winkler, and “The Danger that Lurks in the Internet’s Core Protocols” by a panel including Jeff Moss, Dan Kaminsky and Anton Kapela.

In 2007 a handful of companies (including Google, Microsoft, and Yahoo) decided to draft a set of guidelines influencing the behavior of online businesses when it comes to the subject of policies and regulations dealing with human rights. It was to be a kind of unofficial voluntary code of conduct initiative thing.

According to this letter(pdf) from Yahoo to Senators Durbin and Coburn:

Principles on Freedom of Expression and Privacy [...] provide direction and guidance to the ICT industry and its stakeholders in protecting and advancing the enjoyment of freedom of expression and privacy globally. The Principles describe key commitments in the following areas: Freedom of Expression; Privacy; Responsible Company Decision Making; Multi-Stakeholder Collaboration; Governance, Accountability & Transparency

Along with censorship and freedom of speech, the idea was also to provide general requirements for privacy. The idea also calls for a way to determine if a company is compliant with the code and a way to hold companies accountable if they violate it.

This is important because it shows that some of the most relevant internet-based companies are taking the rights of their users seriously. So seriously, in fact, that they are willing to sponsor a set of guidelines that help other companies protect THEIR user’s rights as well. If more companies get on board, this could be a step in the right direction in helping to strengthen the trust between service provider and user.

We’re constantly looking over, analysing, and adhering to narrowly defined security standards in the IS field. These standards are focused on large companies, yet what is there for the little guy?

Websites slap on labels like “Hacker Safe”, which we don’t trust and there are countless blogs vulnerable to a number of security holes, gaps, and simple poor configuration.

What we need is an open-source set of general security recommendations and guidelines for a host of applications – encryption, blogs, and even social networks. The formula for these guidelines to work, be useful, and adopted are,

• Keep Them General - Don’t include specific instructions on how to configure a setting.
• Have Input From Independent Security Experts – The people that work, teach, and have “intangible” experience working in information security.
• A Ranking System - What something protects against, how effectively it does it, and how difficult is it to configure.

Such a set of open source standards, would do wonders for not only the people using them, but the companies that stand behind them. Especially smaller companies who can respond quickly, speak more freely with the public, and have a more varied palate of work vs. a large corporation.

Why not have a set of well-scrutinized general security guidelines that could be adopted by schools, independent consultants, or Web developers?

Cisco unveiled a blueprint to address Payment Card Industry data security for the healthcare industry.

The blueprint is intended to provide healthcare organizations with a model for safeguarding patient financial transaction data and other personally identifiable information that is captured and processed within a healthcare facility or retail pharmacies. Called PCI for Healthcare Solution, it offers design and implementation guidelines to protect credit card, patient demographic and employee information.

Stats collected by Cisco are showing that external data security related attacks on the healthcare industry have increased 85% between January 2007 and January 2008. One in four healthcare executives do not know where their sensitive data is located, the vendor says. Also, many organizations do not have a security framework in place to provide optimal protection.

I like this idea because it shows a strong cross reference between two completely different types of industry (retail / healthcare). It shows that standards and practices that have already proven to help secure and improve industry trust, can be carried over into other forms of industry. The healthcare industry is already heavily flooded with many standards of it’s own that one would think there wasn’t anymore room to grow. But something like this, if implemented correctly could be a helpful hand in an over saturated area.

On June 30 2008, the new revisions to the PCI DCC v1.1 will become mandatory. The main item that may be of concern is in 6.6.

Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:

• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security

• Installing an application layer firewall in front of web-facing applications.

In the current listing of the specifications it is advised that these methods are considered best practices, but after June 30, 2008 they become mandatory.

A lot of questions and concern have been brought up about this. Is every company going to have to have a line by line code review by an outside source? This has been addressed by the PCI council.

The application code review option does not necessarily require a manual review of source code.

Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities (such as those listed in Requirement 6.5), several possible solutions may be considered.

They are dynamic and pro-active, requiring the specific initiation of a manual or automated process. Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools

I think having your development team properly trained in the areas of secure development should also be a good measure. So if you fall under the requirements of the PCI, don’t forget to keep up with your standards.

We have all heard about ISO 17799 and ISO 27001; ISO 17799 is being renamed to ISO 27002 and ISO 27001 was formally known as BS7799-2. If you haven’t and your reading this, stop now and go look them up. Here is a good place for an general overview.

These standards are the basis of least requirement for doing business, when security is concern. Instead what you see are most companies, those that care and especially here in the US, are still in a phase of “working towards” meeting these standards. Very few western organizations have implemented or even looked at these standards. In Japan over 2000 companies have been certified meaning that Japan dwarfs any country by at least 300% more compliance than the UK and the US put together.

Something needs to be done to bring the compliance level up. Especially when it comes to the base foundation for security controls and ISMS.

So what can you do? Here is a 10 step guide to becoming certified.

1. Prepare the ground: obtain copies of the ISO 17799 and BS7799-2 standards, research the background, set the objectives, understand the costs and benefits, and liaise with senior management to gain their support.
2. Define the scope: what’s in, what’s out, including issues like location, assets and so on. Prepare a Statement of Applicability.
3. Define a formal ISMS (Information Security Management System) policy.
4. Analyze the information security risks to identify the corresponding security control objectives.
5. Prepare a security implementation plan describing the implementation of specific information security controls to satisfy the objectives identified in step 4. Gain management approval and secure the budget.
6. Implement the plan. Prepare, review, approve and publish information security policies, procedures, standards and so forth. Bring controls protecting the IT infrastructure and facilities up to scratch. Review and where necessary improve application security controls. Prepare and exercise contingency plans.
7. Operate and maintain the information security management system. Keep records to document proper use of your system (e.g. information arising from the review of system security logs).
8. Perform an information security audit and management review to check that everything is in order (this typically involves an informal pre-certification assessment by the certification body).
9. Make any last-minute adjustments to the information security management system to address issues identified in the pre-certification assessment.
10. Undergo the formal certification assessment by an accredited certification body.

Source