Today, in advance of the 2010 RSA Conference, I had the benefit of attending the 10th CSO Council Bay Area Round Table: The Last Mile: The End of Paper. It has been an interesting exercise with a mock trial (moderated by two Judges) involving three wills signed with three different technologies: ink signature, closed system electronic signature, and digital signature.

You would think this would be an easily decided scenario; the digital signature is a superior and more trustworthy technology, right?  Well, not when you change the rules a bit. Basically they made the strength of process the inverse of the strength of the technology.  Here are the key points from today’s trial, and I’d like your suggestions on which one you’d pick.

• Will 1: Ink Signature: happened a long time ago, seems to be in order but there are no surviving attesters to the signature. Gives the entire estate to his wife, and if she predeceases him, his son.  As of today, the wife did predecease him, and his son has become estranged, will #2 being part of the reason.
• Will 2: Electronic Signature: signature is just a hash of the user name and the document being signed.  Gives 1/2 the estate to Stanford University, and the other 1/2 to his son.  The signature was not attested to by any other individuals.  There are no security controls over the log files and no way to prevent modification. However, everything seems to be in order with the signature.
• Will 3: Digital Signature: signature uses the internal PKI of a legal firm which stores private keys on USB memory sticks (not cryptographic devices). A paralegal of the firm who helped create the PKI process is the sole beneficiary.  The signature was counter-signed by two other individuals.  The paralegal (“Bubbles”) administers the PKI system and theoretically could have recreated signatures or digital IDs.

So, if you had to vote for one of these as a juror, which one would you choose?  Personally? I think all 3 are terrible and I fear the entire estate may need to go to probate.  Let us know what you would choose as a juror in the comments.

SearchCompliance.com has posted an article detailing important regulatory compliance trends that will affect IT in 2010. The trends that were listed include:

• Automation of compliance processes
• More regulation en route
• FISMA compliance reform
• More enforcement for noncompliance
• Federal data breach and privacy laws emerge
• Cloud computing complicates compliance
• SOX compliance for small companies
• Migration to risk management

I was quoted in a couple parts of the article with my visions of the future related to FISMA and risk management. It’s worth a read and a comment if you think they missed anything, or if my predictions are way off!

Dan Kaminsky posted on twitter the following:

http://eprint.iacr.org/2010/006.pdf Is it time to deprecate 1024bit RSA for, say, 1276bit? (2048 has perf issues.)

The link Dan provided is a research paper which reports the successful factorization of the 768-bit number from the original 2001 RSA challenge. I responded to him that NIST had already deprecated the use of 1024-bit RSA in the government, and it was time for industry to follow suit. Since I posted that, I’ve been surprised that a number of people don’t understand the upcoming changes in key lengths and algorithm strengths that have been mandated by NIST. So, this post offers some information about why I can confidently say the U.S. government has deprecated certain algorithms and key lengths.

(more…)

As a recent slashdot article points out, Amazon has honestly admitted that it is impossible to attain PCI Level 1 compliance on an application built on their EC2 (computing) and S3 (storage) services.

It is possible for you to build a PCI level 2 compliant app in our AWS cloud using EC2 and S3, but you cannot achieve level 1 compliance. And you have to provide the appropriate encryption mechanisms and key management processes. If you have a data breach, you automatically need to become level 1 compliant which requires on-site auditing; that is something we cannot extend to our customers.

We wrote a short whitepaper covering a brief security overview of cloud computing, and this is one of the topics we have been concerned about.  I’m currently en route to perform an on-site assessment of a service provider for a customer of ours.  This type of assessment provides my customer a great deal of confidence that they can trust their business partner.  If the provider of cloud services either won’t let you (or your auditor) visit their data centers, or can’t tell you which one to visit (because your data is unpredictably stored in many different locations), then it is impossible to get the same level of confidence that your data is being stored and protected.

Cloud computing isn’t for everything. It’s not going to be a good fit when you need compliance with PCI or similar standards, or your security policies require on-site assessments. Kudos to Amazon for admitting that.

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