Assessments .... Everyone should understand what the goal is

I know .... I have been quiet for a while .... ok a long while. That being said I have not disappeared and this topic has been one that has been near and dear to my heart over the last couple of years in particular.

Unlike many security professionals I do not dread assessments, accreditation exercises or any other sort of measurement criteria that is placed upon a system that I have either built, helped write policy around or have architected. I find the assessment exercise an educational one. Sometimes I find the educational aspect is that the assessors need to do a better job.

It is important when you look at assessments that they be viewed in light of the goal of the assessment. I have never been put in a position where the goal was to just fail the system being assessed. One of the reasons that happens is that I make sure I am involved upfront such that there is clear understanding of things on all sides. I want to know that the assessors understand the system and understand where some cookie cutter tools or criteria will not be demonstrable in the "standard" way. I have dealt with systems that have Linux OS built on a couple of hundred of packages versus the few thousand that is standard. I can assure you that  standard tools are not going to work in trying to assess that system. 

I have also been involved with systems where the assessment criteria is utilizing old or poorly written measurement goals. Believe it or not some have stated you must implement <> of <> rules. Pretty hard to successfully measure or defend against a finding there.

When it comes to an assessment, accreditation or audit I tend to like to follow a pattern to ensure that everyone is getting the most out of the exercise. The process for me does not change whether I am assessing or being assessed. The question/responses may change but the overall process is one I find gives the system/organization being assessed the best chance to ensure that the security of the system meets the business requirements of the organization. The flow I use includes:

• Ensure documentation is up to date and available in advance;
• Define the specific criteria for assessment and agree up front to what those criteria must entail;
• Ensure the assessor has been given an introduction to the system so they understand any challenges to assessing;
• Ensure that people with practical knowledge of the operations are available as well as people with the deep technical knowledge can be called upon quickly;
• Allow the system owner to review a draft report of the assessment;
• Work with the system owner to ensure clear understanding of the gaps in the implementation versus the defined criteria from above;
• Define a clear path to remediation with the System Owner.

The goal here is not to see how many flaws can be found but to ensure that whatever is found is clearly understood, that the system owner understands the possible risk and that a mitigation plan can be defined and delivered on.

I have been involved in assessments where the assessors try to get in and out, as quickly as possible, and assume the standard tools work in all environments. In the end the assessment comes out as a very faulty one. It has not truly assessed the system and in the end it looks bad on everyone. I have also been in assessments where a few things have been found that could improve things but the assessors walk away with a high degree of confidence that the system truly meets the criteria defined and the devil in the details is what is needed to clean up .... and clearing those details will certainly help the system owner in the long run.

Don't be afraid of assessments. If you have done your work and you work openly with your assessor it will be a success for all.

Ignoring Security Policy Reviews

I had an experience this weekend that made me think about policy and how it can be something to ruin your business very quickly. Interesting enough this was not an information security policy related event but the process of what I went through made me think about how a company can really screw up by not being aware of the global environment they operate in.

The incident ..... being a security guy I do take advantage of security aspects that are provided by others. My credit card company has a system whereby I can generate single use credit card numbers for online purchases. I can even use reward points for these purchases. With this in mind I was looking for an inexpensive monitor for my home office so I went online to BestBuy so I could see what they had and since there are two locations near me I could go and quickly pick it up. I found one that was suitable, quickly generated a credit card number and placed the order. Within half an hour I had the "come get it" email from BestBuy. It did mention for me to bring the email, my ID and the credit card. Well the card is virtual, generates and disappears, but I had the source card. Off to Best buy where they promptly refuse to allow me to pick it up. The associate claims they do not allow virtual credit cards for in store pickup. I ask why and the response "It is policy." Well it seems to be a silly policy since you can easily do a trace back to me with my ID and the email and the fact that it all matches the data I provided for the online purchase, which cleared the credit card check. "It is policy". Then he stepped in it deep - "But ... if you have someone else pick it up and you say who it is at check out then it is ok since they do not have to show the card."

WHAT!!!!!!!

Someone who skims my card and gets the number, CIV and expiry can go online, buy something with my card and put their own name as the guy picking it up - BUT - I cannot?

"It is policy"

It dawned on me - BestBuy created a policy many years ago when virtual credit cards did not exist and they had not updated that policy with this new paradigm in place. Sure a few years back it was good practice to want to see the card but to update the policy to let someone else pick up and not update it to handle virtual cards or currency?

Imagine now that this is a IT security policy. With the recent BASH vulnerability announced, would a company now start to look at where they are using CGI and Linux systems to see what they need to do from a policy perspective for future protection? A good company may even do an evaluation of other aspects of operations to see if there was any open-source code that maybe was also created before certain vulnerabilities were leveraged.

The lesson for me, outside of don't shop at BestBuy, is that security implementation and policy is not about a document or a configuration. Security is about taking what is happening today and ensuring that you understand how that impacts your business and mitigate any risks - look to the future but ensure you understand what you are doing today and what others are doing that may potentially put you at risk.

BTW - used the exact same method for a purchase at Apple - using that keyboard to type this post .... no card needed.

The Learning Process Seem Hard .....

Once again mis-issued certificates are in the news. I would like to be able to say that this will not happen again but it seems that not enough people are willing to learn the history of Identity Management to begin to implement mitigation means that would reduce the impact of these events.

This time around it was an Indian Government Agency, NIC, that was in control of the issuing CA. Part of the process did work here in that the Indian Government's Auditing reacted fairly quickly to the issue and revoked the Issuing CA and for now has no plans to put that CA back online. That being said the work that Google and Yahoo will have to do to ensure that vulnerable browsers and Operating Systems take the correct action to mitigate the risk is not insignificant. On top of that we do also have the case that we are not sure that Google and Yahoo were the only ones affected ... at least not yet.

The timing of this for me is quite interesting as I am currently working with a client who is looking at options for certificate based authentication, both privately rooted and publicly rooted. They will use a hosted service but I was very insistent that they make sure to implement smart card based authentication for all administrators and then to ensure to implement practices and policies of log reviews to ensure that the known administrators are adhering to policy.

Sounds simple doesn't it? Implement a stronger means of authentication for RAs and LRAs and then review the issuance logs, which can be done automatically. So given this why are people not doing this? Yes some are but there are still many issuing CAs out there that allow RAs and LRAs to login with userid/password.

If you are a corporate or organizational Security Officer I encourage you to do a couple of things:

• If you operate a CA or operate an RA/LRA for a hosted or public CA service then implement strong authentication for the credentials used in the issuance process. If your CA vendor does not support that ... CHANGE VENDORS
• If you operate RAs or LRAs ensure that you run checks on a regular (preferably daily) basis to ensure your RA/LRA personnel are not compromised. This could be fully automated through scanning of logs
• If you have not gone through the Trusted Root stores that are used within your environment you should have that task looked into and clean the roots that you do not use.

Again these are not difficult things but my experience tells me that these things are not being completed across the board. If you want to stay off the front page of technical blogs and magazines I would suggest that taking some of the points above and start to implement them.

Again - history is a wonderful teacher .... but you need to understand history and how that history affects what you do

Target and Snowden ... two cases with the same root cause?

As greater information comes out about the Target breach one begins to wonder if it and the method used by Snowden, to access the information that he disclosed, point to a fundamental misunderstanding when it comes to implemented "best practices" in information security.

I certainly agree that the range of implementations of different security architectures represents a broad range of very bad to good, when it comes to protecting access to information. I am also a believer in the balance between ease of use and "appropriate" access to information. I am not suggesting that one size fits all. What I am suggesting is that we have two significant examples here that point to, what appears to be, a glaring gap in what some would see as fundamental principles as it applies to access to information, that is, access should only be granted to the right people at the right time for the right reasons.

In the two cases here we have two very different organizations but at their core of operations you have two organizations that share data, both as a supplier and a consumer; interact with a broad range of organizations (Target's case it's suppliers and the NSA case it is contractors) and have legislative or contractual mandates to protect the data that they hold.

What is interesting is that in both cases we had entities able to have access to more data then they needed to have access to. Yes Snowden did go outside the box in some cases to gain the data but that was not caught, which points to the possibility that they were doing things correct on the front end but had weak audit mechanisms/checks to validate the implementation. In Target's case it is obvious that the external supplier that they were dealing with did not have access restricted to systems that were irrelevant to the relationship.

These are not the first cases of significant data loss occurring because of access to data that occurred indirectly. Fundamentally the RSA breach was the same thing ... in that case it was data being on a server that should not have been exposed in the manner in which it was. If a server does not have controls to restrict access appropriately then do not have exceedingly sensitive data on it.

Fundamentally organizations need to get back to data categorization and map that to data access. Data access however is not just a case of yes or no based on the credential you have but has to be considered in relation to the credential you have (considering strength, assurance level etc), situational analysis (Is something going on in the network that raises suspicion of activity such as excessive data egress), timing (Is access be requested at an hour that is inconsistent with past behaviors?) and other factors that may need to be considered based on the environment or data sensitivity.

This process of data categorization will lead to system dependencies that will need to be well documented in security and operational plans. Once these plans are implemented there also need to be the process of validation and audit/monitoring that needs to happen to ensure consistent operations.

Some would say "This is not rocket science ... people know this". I think more people are thinking of it now but if they have known it certainly does not appear to be widely implemented in a complete fashion.

Sacré bleu! Another CA Scam

This weekend Google security engineer, Adam Langley, (we will get to the irony of the last name in a bit) blogged about an agency within the French Government and its misuse of its intermediate CA. The French cyber-defense agency, ANSSI, had improperly issued "duplicates" of certificates for some Google domains. It appears they went as far to ensure that the certificates carried enough information to display to any user that the certificate was the legitimate site certificate even though it was issued improperly. Google has started to work with the browser manufacturers to effectively block this intermediate so look for browser updates over the next few days. ARSTechnica article is here.

This does raise some interesting thoughts. First off is the fact that Langley (has anyone else made the link to the other "famed" Langley location and the fact that ANSSI is the "cyber defense" agency in France?) was looking at these types of organizations given the recent announcements from Google, Yahoo, Twitter etc as to the push to rein in the NSA programs for monitoring. It appears that Google, and likely others, will be doing some checks that the operators of the Global Roots should be doing all along and sampling the certificates issued by the intermediate CAs. This sampling usually only takes place after the car has gone off the cliff. I had to go through every issued certificate for our CAs after Diginotar - "just to make sure". But a sampling on an irregular basis would do wonders for issuance confidence.

So if we are to assume that the Root operators are not doing their jobs to protect the issuance process what do we do? Well options have and are further developing. One of the most promising is certificate pinning - which provides a way to link a site to a specific certificate and even if another certificate from a valid CA appears to be valid it will be ignored. It does seem to me that we should not have to do these things but since we cannot rely on Root operators to protect their brand then we need to do things to protect ourselves.

For those CA operators out there - make sure you either have good control over issuance OR put in place mechanisms to randomly audit issued credentials so you can provide a way to protect your brand.

Another case of what is old is new again

It has happened again and one has to ask what it takes for companies to learn from their mistakes.

I think everyone has read the articles on the latest Adobe breach and the disclosure of records of users. Of course we are not talking about a small number of users - we are talking 150 Million accounts, 38 Million of them active and 2.9 Million accounts with credit card information. The data that was taken included:

• clear-text email addresses
• hashed passwords
• encrypted credit card information
• clear-text hint lists

It is unknown how well protected the encrypted credit card information is but certainly the clear-text email addresses/usernames and clear-text hint lists create significant threat to users especially when some of the hints were "Same as bank account". 

The hashed password list is a significant issue as it appears that these were just hashed - no salt values were used to make the hashed password more complex.

Of course this is not a good situation for Adobe customers or Adobe itself. Even worse for Adobe - this is not the first time this has happened - not even the first time recently. In 2012 the Connect conferencing forum back-end was hacked and a similar data trove taken. In 2012 approximately 150,000 users were exposed. The data taken - clear-text email addresses and MD5 hashed passwords with no salt values used. It was not like this breach was not made public as the purported perpetrator released a screenshot of 230 of the user accounts. 

So why has Adobe not fixed their back-end for storing of customer data? Adobe does know that they are a target - these were not the first attacks against Adobe - in the same 2012-2013 period you also had the hack into the signing process that allowed malware to be signed using Adobe credentials and; the theft of source code for Acrobat, Cold Fusion and Photoshop that eventually led to two well known attacks against PR Newswire and the Washington State Court System.

We have talked about the simple processes before - be aware of what you are doing and using in your systems such that when vulnerabilities are being exploited against those same tools and processes you use you can be aware and implement changes to protect yourself. Adobe did not even do this when it was a vulnerability that they had before.

I am not suggesting here that Adobe needs to be put in the corner with the dunce hat on but for users that may have accounts with Adobe learn the lesson that Adobe did not - and rather than exposing yourself to attacks because of password reuse use a methodology of unique passphrases across your essential accounts. If Adobe cannot do anything to protect your data - you certainly can.

The Little Things

Yesterday I had an opportunity to catch up, over lunch, with a good friend and colleague. One of those lunches that is truly to catch up but also to see how business is going and to see where the next opportunity is. 

During the course of our conversation he was commenting on the lack of funding that agencies had dedicated to his area and commented that even though he sees lots of heads nodding in understanding of the problems he addresses that they still do not seem to see it. To them it is a little detail that seems like it can wait. 

The comment about 'little detail made me think about all the little things that are missed and cause problems today. I do not mean just in the cyber security arena but in day-to-day life: the driver who does not look left and right when entering an intersection and causes an accident; the driver who is not attentive when backing out of a parking spot and destroys their passenger side mirror on a post (saw that one yesterday after lunch); the parent who does not secure their firearm properly only to have their 8 year-old shot their grandmother; and there are many more. 

Of course some of the impacts are trivial but others are clearly catastrophic in their effect. Cyber-security is not that different. Inattentive implementers may leave an opening that allows someone to get into the network where they should not be. Improper design or implementation can lead to that false sense of security and make your environment a haven for cyber-criminals or terrorists. Of course it is not just about the design and implementation, it is also about the planning, policy, people, audit, testing and operations. These things are all important. 

For my friend it is all about monitoring and managing identity. An expired credential, a credential that should not be on a system or, a credential that does not meet policy. All these seem small and easily managed on that one system - but who has one credential on one system? There are hundreds of systems, with thousands of credentials within most environments, whether on your premises or in a cloud implementation. Managing that environment now requires some thought, planning and resources. Is it really a small thing now?

Be aware of the small things .... they can lead to the big problem if ignored or trivialized.