Identity Experiences & Ideas

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

noreply@blogger.com (Gary) — Mon, 14 Dec 2020 22:01:00 +0000

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

noreply@blogger.com (tricdn) — Mon, 06 Oct 2014 19:33:00 +0000

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 .....

noreply@blogger.com (tricdn) — Mon, 14 Jul 2014 15:26:00 +0000

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?

noreply@blogger.com (Gary) — Mon, 10 Feb 2014 15:55:00 +0000

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

noreply@blogger.com (Gary) — Mon, 09 Dec 2013 21:10:00 +0000

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

noreply@blogger.com (tricdn) — Mon, 25 Nov 2013 15:04:00 +0000

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

noreply@blogger.com (tricdn) — Wed, 28 Aug 2013 14:56:00 +0000

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.

M2M Making Buildings for Greener

noreply@blogger.com (tricdn) — Thu, 11 Jul 2013 15:23:00 +0000

I read an interesting article the other day about "smart buildings". The concept is not new but recent advances have made it even easier to cost-effectively implement systems that allow more efficient control and even provisioning within these buildings. The article stated ROI within 2 years.

Being a self-confessed geek I loved this thought. Think of remote management of building control systems, whether power, water, alarm, heat/cooling, entry, etc. The operational benefits are huge and potential reduction in personnel costs, or automation is great.

Being a security guy the personal alarms were going off since this article did not speak of the need for effective security management. When I think of M2M the first thing that comes to mind is strong identification and authorization of systems and secure channels to protect from alteration of data in transit. The possibility of abuse without effective controls is significant and dependent on the tenancy of the building the risk will vary greatly.

So yes I love the idea of smart buildings using M2M to improve the operational and cost-effectiveness but please ensure you think about the security implications in the context of the business drivers before you start.

The attack against Cyber-Identity continues

noreply@blogger.com (tricdn) — Tue, 09 Jul 2013 16:39:00 +0000

I have many friends who may be considered cynics. Now these are not all people who are running around with foil lining their hats, but there are a couple that may just be in that category as well, but they are people that tend to believe first and maybe look into the verification aspect later.

Now coming from a security guy that opening paragraph may seem odd, especially given the title of this post, but let me explain. I am not one to believe that things that happen are inherently altruistic or inherently exploitative, I instead tend to believe that at any point either may be true and one needs to look at the context around something to see where on that "altruistic-exploitative" spectrum that something may fall. The key point is it rarely is black or white and that often there is some other colour injected into a circumstance that changes the hue. It is this base of idea that I work from when I look at cyber-security as well. when we look at things from a singular context we often lose sight of the environment and as such make decisions that may end up masking the real issues.

When it comes to Cyber-Identity this is often very true as when many people look at term cyber-identity they immediately fall into the "login credential" mindset. yes the login credential may be a cyber-identity but cyber-identity is so much more than that and this is where organizations are missing the big picture and thereby leaving real risks unmitigated. A couple of recent examples of this are in the vulnerability within the Android operating system and a SSH key compromise in Emergency Alert System (EAS) devices.

In the case of the Android vulnerability (documented by Bluebox) this was not a stealing of a credential but an attack that has some similarities to the FLAME attack. The vulnerability that exists has been around a while and effectively allows an attacker to modify signed code without the operating system being able to detect that the code has been altered. What does that have to do with identity you ask? Well the reality is the signature itself is intended to assure you that the code comes from its creator and has not be altered .... in fact to identify who created the code and has control of it. The reality is that with this vulnerability there are circumstances where we can no longer be assured of the identity of who produced the code/application.

In the case of the EAS device someone was able to obtain the SSH key that is embedded in the firmware of a certain set of a vendor's EAS devices. This effectively allowed them to take control of the devices and to create some interesting alerts - "Zombie Apocalypse". Steve Ragan wrote an interesting piece on it. This case highlights the threat of an embedded, permanent identity, that apparently was shared across the devices as it was embedded in the firmware. As soon as this key became know then all devices with those firmware instances became vulnerable. This situation is one where both sides can debate the threat/risk of using a shared identity as it certainly makes manufacturing more efficient but at the same time opens the door to whole scale firmware upgrade when an exposure happens. This is a great case of why the business need and security need have to be looked at together - and when I say security need I am referring to not just that of the vendor but the downstream effect, which in this case could be catastrophic.

What both vulnerabilities have is a totally different view of what identity is in the cyber-world and the very different need to consider when addressing mitigation. Both of these situations were avoidable, from a pure technical perspective. The question becomes when these systems were designed how big was the threat at the time and did that impact the threat-risk equation? We may never know but it does suggest that maybe, just maybe, we need to be more diligent about revisiting our equations when the system cycles through the technological generations.

Trust is the New Attack Vector

noreply@blogger.com (tricdn) — Sat, 23 Feb 2013 19:57:00 +0000

OK it may not be the "new" attack vector but it has become a popular one to exploit.

So what does one mean when they say "trust is an attack vector". Lets go back to the simplest ways that have been used to garner information about people or companies - the phone call. Your office phone rings and when you answer it the person on the other end immediately starts talking in terminology that you are comfortable with and dropping names of people in your organization. At this point a majority of people will drop their guard, at least to some level. If the questions start to get more and more deep into information that you think this person, who you have begun to trust, should know then the guard begins to go back up. This is the simplest form of the "trust attack vector" and we commonly refer to it as social engineering.

In the electronic world it is a bit different as there is no person to interact with and secure protocols exist so we know the entity we are dealing with ... or do we. Over the last couple of years there have been a number of attacks that utilize this assumed trust to deliver malicious payload by doing much the same as the "social engineer", that is they provide enough information that allow the process that they are dealing with to trust the transaction. In the online world that first trust transaction will usually involve you getting in the door of the system or application.

So how does this really work? Trust in the online realm is based around a shared secret or a cryptographic operation - either I have a password to use or; there is a common shared cryptographic key or a public/private key pair that is used to establish the transaction. More and more systems are utilizing the cryptographic option since passwords can be directly attacked and are hard to share when that is needed (of course symmetric key distribution can also be a challenge but that is a side conversation). So today many servers and applications use private/public key pairs to establish trust. These key pairs are used to establish secure channels such as SSL/TLS or IPSEC tunnels. Symmetric keys are commonly used to establish SSH connections. If these systems are properly configured and use strong algorithmic choices and key sizes the cryptographic aspect is very difficult to attack. In reality the cost of the attack is not worth the value so attacking the cryptography is rarely seen (exceptions are in cases of weak crypto such as seen in the Flame attack). So instead an attacker will go after a system to gain access to the keys themselves. This can be done by going after the Registration Authority that is the interface to key issuance (Comodo attack) or hack into the system using other attack vectors to gain access to the keys to the process that uses the keys to sign data (Adobe attack). Once they have this access then they can generate attacks against other systems.

A recent example of this is the Bit9 attack. Recent data suggests that the attack was initiated with a SQL injection attack against an internet facing web server which had been turned up with an old certificate. This attack planted a root kit that was signed by a stolen certificate. Once inside Bit9 the attackers used Bit9's signing keys to sign their own malware. Bit9 customers that were targeted would believe that the code they were executing was trusted as it was signed by the Bit9 keys. of course this is just one example of keys and certificates being used to obfuscate the trust chain.

So trust is being used as an attack vector- what can be done about it? There are a number of things:

Know what is in your network when it comes to the trust infrastructure. This means:

Know what certificates and keys are being used and why
Ensure that cryptographic assets that are used in your environment meet your policy for strength, lifetime and algorithmic uses
Ensure every cryptographic asset has an owner assigned to it and that you can keep that data up to date

Clean your Root stores. In any organization you will have a variety of Root stores. These Root stores are used by applications and the operating system to help build the trust chain. The reality of the situation is that off-the-shelf Root stores delivered in applications and operating systems has many more Roots installed than you will ever encounter. It is important for an organization to trim down those Root stores and maintain oversight of them to ensure that Roots that should not be in the stores are not introduced or re-introduced.
Maintain a central view of the trust environment. The two pieces above can, in themselves, be challenging so it is important that you have central oversight of the environment, be able to recognize changes and then react accordingly.

As I have always said, there is no silver bullet for security other than disconnecting all external communications and interaction from a box. Outside of that the best actions are those that mitigate risk and two important steps to mitigating risks are knowing what is in your network now and knowing what gets introduced into your network. This is especially true when it comes to trust.

Some Thoughts from Suits & Spooks DC

noreply@blogger.com (tricdn) — Wed, 13 Feb 2013 12:34:00 +0000

It was an interesting two days at the end of last week. Enough "security professionals" to fill a room and then some at the Waterview Conference Center in Arlington, overlooking the Potomac River. All of these people were brought together by Jeffrey Carr as part of his ongoing Suits and Spooks conference series. Jeffrey always has a great set of speakers and more often than not the bringing together of such diverse talents, backgrounds and personalities creates some intense discussions. Suits and Spooks DC was not any different.

There was a lot of discussion during the two days on the international aspects of cybersecurity. The ongoing risk of state sponsored activities for intelligence collection and IP theft along with the international efforts on reaching agreement on cybercrime cooperation, as discussed by ITU representatives. We also had opportunity to hear from people who were involved with some of the international cases including the Russian Government efforts in Georgia and Estonia as well as the recently published Red October attacks. Other sessions brought up the Duqu/Flame/Stuxnet series of attacks and shared some of the research done in investigating these attacks. In all of the attack discussions it was clear that the speakers and the participants at the conference felt that the majority of large scale attacks were not based on new vulnerabilities or new approaches but were based on implementation of existing attack vectors with some modifications. In many cases some of the attacks were successful based on combinations of spearphishing attacks and taking advantage of existing vulnerabilities such as SQL injection attacks.

One of the other interesting aspects of the conference was an ongoing, and at times heated, discussion on the idea of cyber-vigilantism. Many at the conference felt that the government has not moved, and some felt is incapable of moving, fast enough to respond to cyberthreats. By the time the government is ready to take action much damage is feared to have been done and like those that are out buying Day 1 vulnerabilities the ship has already sailed. To address this issue some felt that cyber-vigilantism, in varying degrees, would help to allow organizations to respond in a near immediate manner. The discussion involved former government and law enforcement personnel, those at senior levels within private corporations and lawyers in attendance, as well as the general unidentified masses. Many valid points were brought up but the thought that seemed to polarize most was that attacking an adversary without clear knowledge who your adversary is would be a serious mistake. Not knowing who you are interacting with makes it impossible to develop an effective strategy and without an effective strategy you are likely to simply instigate a cyber-arms race with you as a target. That being said there did seem to be broad agreement that action on the private sector needed to be done to ensure stability within your system when it has been attacked and action could or should be taken to ensure the attack is mitigated and your environment stabilized such that business operations can continue. This should be done in a manner which would preserve evidence for future civil or criminal prosecutorial action or government involvement. It was a continued and, at times, interesting discussion.

One of the other presentation I thoroughly enjoyed and felt was very informational, from a business operations perspective, was by Josh Corman and David Etue. They quickly laid out a CxO level view of how to look at cyber threat and how to weigh response investment. It was something that peaked many attendants interest and certainly warrants looking at further as it is a methodology that in the shortened presentation seemed to take the logical business view to cybersecurity.

The lessons that came out of this conference are interesting based on the original conference premise - Cyber Offensive Strategies. I think many left the conference with the view that building your organization cyber plan around the idea that "Offense is the best Defense" is not the best investment. Instead it was obvious that many attacks today relied on organizations missing the simple things. It was interesting that the conference started on the day that Bit9 announced their breach and it appears from Bit9's own admission that theirs was a case of missing the simple thing of installing their own software on all their servers. The Bit9 attack itself is still being investigated but the methodology of using the Bit9 code signing service is again very familiar to those that saw the Adobe attack late last year.

So what is old is new again and we must be diligent about our security planning and operations. We must know and understand what is in our networks and what we should trust. We should ensure we patch vulnerabilities when the appropriate patch is available and in the meantime mitigate against those vulnerabilities. We must pay attention to the attack vectors that are being used as part of our ongoing awareness and then build appropriate actions into our plans. We must understand what are the priorities as it relates to our assets and resources and understand who is coming after them and plan and defend proportionally. Those are the things that will help us stay mitigate the risks we have. If we want to extend that help then the best thing we can do is to share what happens to us and to share best practices as to how to mitigate the risks. Think of it as paying forward.

What is old is new again .... again

noreply@blogger.com (tricdn) — Mon, 11 Feb 2013 15:37:00 +0000

The timing could not be more interesting. Friday and Saturday I spent with a bunch of "security professionals" at Jeffrey Carr's Suits & Spooks. Of course one of the topics that came up was the Bit9 hack which KrebsonSecurity did a great job of highlighting. The hack was fresh of course but it also highlighted something else that was talked about frequently over the two days ... not all attacks are new. In fact numerous discussions highlighted the fact that most attacks are in fact based on using existing vulnerabilities that have not been patched or using existing techniques that still work.

Bit9 is still being looked at but it appears that the attackers goal was to gain access to the digital signing capabilities within Bit9 to sign their malware. The method would allow the signed malware to run unchallenged in a Bit9 customers environment. If they were someone who thoroughly drank the Bit9 kool-aid then they may not even have anti-virus running. It is interesting to note that the Bit9 blog had just posted an article on why a/v is not effective but it seems that the malware was caught in one of their customers environments by a/v software.

Of course the point here is that there is no one silver bullet. While whitelisting can be effective it is not the only answer. Anti-virus can find issues but on its own it leaves many gaps due to how vulnerabilities are identified and updates distributed. Security is about having a comprehensive plan targeted to your environment, utilizing process and tools that work together to mitigate the identified risks. Many of these ideas came out during the S&S conference and I will be posting some more on those thoughts in the next day or so.

The Future of Trust

noreply@blogger.com (tricdn) — Tue, 05 Feb 2013 19:47:00 +0000

We talk a lot about trust in the world of security. "Do we trust the code?" "Do we trust that the user is doing what they should?" "Do we trust that the email or website is safe?" But what do we mean by trust in these circumstances?

Trust was once one of those things that laregly involved experience. It may be your experience or an acquaintance's experience but it was based on experience. I put trust in a mechanic because my best friend recommended him based on his experience. My experience may change the degree of trust I have but that initial trust is based on my friend's experience. I trust that my doctor will give me good advice when it comes to my healthcare because my experience tells me that he has not done anything for me to expect anything else.

In my mind trust has to do with expectations. Will the outcome of some event be what was expected and desired. When I receive an email from an email address that indicates it is from a work colleague will I discover that it actually is from that work colleague, that they created and sent it to me, and that it has not been altered from the time they created it until the time I read it. Of course there are all kinds of elements to this idea of trust but I believe that, fundamentally, trust comes down to the result of some action requiring me to "trust" something being what I expected to happen given my believe of the factors around that trust decision.

Now this is where it gets interesting as trust does come with "qualifiers". I may go to a restaurant, based on a recommendation from a friend, but I may have a different expectation then going to a restaurant I have visited in the past. This differing expectation may be the result of knowledge that I have different tastes or expectations as to quality than my friend. So my level of trust that I will have a GREAT meal may be different depending on why I choose this restaurant.

Of course these are very simplistic views of trust and largely based on known personal relationships. This environment is not the world we operate in today. Today, beyond the personal relationships, elements of trust are in just about every facet of our electronic life. Zappos' web servers trust me based on the fact that I know a username and password combination. Zappos raises the level of trust based on past successful transactions and knowledge that I demonstrate in the transaction process. I trust websites based on data presented to me about the SSL or TLS connection. The Hootsuite authentication server trusts in the MyOpenID authentication service when I use MyOPenID to logon to my Hootsuite account. Whether it is machine to person, person to machine or machine to machine there are elements of trust that affect us each and every day.

Of course for businesses they need to ensure that they are mitigating the risks associated with the trust they are putting into these transactions, based on many factors. These same businesses must also demonstrate to other businesses that they are implementing processes that will raise the trust level to an appropriate level for transactions. This may be in the form of strong authentication protocols, properly protecting data in transit and at rest, and effectively protecting the infrastructure from damage. A gap in the processes may allow bad transactions, a loss of data or a loss of service. A business that faces these exposures then faces the possibility of financial loss, brand damage or public exposure of the loss which in turn has follow-on consequences.

Of course all of that is today, in a world which is vastly more impacted by technology than 100 years ago, or for that matter even 20 years ago. Now lets think about ten years from now ....

Today we have UAVs flying overhead but ten years from now there will be UMVs (unmanned motor vehicles). What will be our expectation then of the trust infrastructure. I live in the DC area and my expectation of manned vehicles is relatively low today but today I know someone is behind the wheel and can react. When these vehicles are unmanned one will need to trust that the intelligence behind the vehicle will be able to react but it will need reliable data from other vehicles, highway signs and characteristics (Slow curve ahead ---- Steep hill ---- Bridge freezes before roadway) and possibly some central facility for routing due to traffic etc. The trust infrastructure here must be able to provide strong authentication and reliability of the data, and in many cases provide privacy of the data as I may not want my home address sent clear text across airwaves.

We need to make sure that today we look at trust as the core element of what we do and what we are building. We have for too long added security, and the trust elements, to applications and business processes after the fact. These ideas of trust must be part of the base design principle. As we move forward with these new ideas of the automated world we will not be able to "learn from our lessons" as the impact of bad design decisions may be significant. Lets design security and trust in from the beginning.

Trust me on this

Is the Energy Sector Really a Cyber Target?

noreply@blogger.com (tricdn) — Wed, 16 Jan 2013 19:54:00 +0000

For years we have heard about cyber warfare - whether it was the categorization of cyber Pearl Harbor or the cyber equivalent of 9/11. Over the last couple of years we have definitely seen the increase in targeted attacks. Some of them generated in Western Nation States while others have been generated in Middle Eastern, Eastern European or Asian nation states. we have even seen, what appears to be, pure cyber-criminal attacks that have targeted resources to manipulate (banks and their transactions) as well as data to sell. The most recent case that has come to our attention is the 5 year odyssey that is now known as Red October.

What has been interesting is that some of these attacks have been built to be very targeted against industrial control systems. People are familiar with the term if they have looked at Flame or Stuxnet. In the case of Stuxnet it very much was a part of a larger operation to leverage the industrial control systems to halt the use of centrifuges. What many people do not realize is that these same control systems are implemented every where. Power plants, manufacturing facilities, water filtration and gas pipelines and the list goes on.

So what we have is a target in a broad environment space that is proven to be attackable. So what does it take to attack these systems? Well an understanding of what type of system is implemented and then basically access to the internet to get the command and control language that is used within the system. Some would say that it is not that simple and that is largely correct as I need to get at the system and these are within environments that are protected by firewalls etc.

That last statement is the false sense of security that we seem to have lived behind for quite some time. DHS recently released a report that indicated that 40% of cyber attacks were against the energy sector. An example was the discovery of advanced viruses/malware at 2 US energy plants late last year. Both of the attacks were apparently delivered through the same mechanism that was used to deliver Stuxnet (so not only are people re-using the code they are re-using the methods). One can surmise that the two plant attacks could have been prevented by following some very basic security procedures, including up to date software and not carrying drives between enclaves without safety mechanisms in place.

It is this last point that becomes the slap in the face to all of us. Congress has repeatedly refused to provide requirements for security for critical systems. There is the attitude that the government should not be telling private industry what to do. I do not necessarily disagree with the sentiment in most cases but we are not dealing with most cases here. There are many critical infrastructure segments but lets focus on energy here. If proper secure protocols are not followed the attacks against the energy sector will continue to be successful and to greater and greater degrees. Yes that is bad for he energy sector because of reputation and and actual financial loss but guess what I am using electricity now to write this blog. You are using it to read it. Your bank is using it to perform transactions that allow economic active to flow. Hospitals are using it to keep people alive. Of course I could go on. It is time that we recognize what has been demonstrated to be true and it is time it is responded to. If Congress cannot pass a "Here is how you fix the problem bill" then lets look to California and their data loss bills and pass legislation that is not prescriptive about how to protect your infrastructure but hold the companies HIGHLY accountable for not properly protecting their infrastructure. There is just too much at risk.

Stepping off the soap box.

Happy New Year ... and you could still end up being a target

noreply@blogger.com (tricdn) — Fri, 04 Jan 2013 16:25:00 +0000

Well it is a new year and with that we can all expect to face new challenges.

That may sound doom-and-gloom-esque but it is not intended to. I truly believe that the problems we have and will continue to face as professionals can largely be mitigated through thoughtful application of combined intelligence and careful planning. Let's be honest - most of the problems we saw the last couple of years were not taking radical new technical advancements into account but rather application of existing processes in different ways, leveraging open doors that people just forgot about or were created by poor process implementation. Guess what - it seems 2013 will not be all that different.

The first "breach" news story out in 2013 is an attack on the Google channel. Did it start as a planned attack against that channel - unknown - but when we look at this breach we will see that it was poor process implementation that allowed it to happen.

So what are we talking about here? Google just announced that they had discovered certificates that were illegitimately issued under their name. Now what is different here is that the credentials that were issued were not apparently issued by breach of a CA or its RA but instead by poor process. The CA involved, Turktrust, issued two certificates in August 2011, with bits set that effectively made these certificates capable of signing certificates, effectively looking like intermediate CAs. According to Turktrust this was caused by the loading of test certificate profiles in the production environment. After this was done the two certificates were generated before anyone noticed the profile error. Once the error was noticed the profiles were removed from the production environment. What did not happen was no one went back through the logs to identify any credentials issued under those profiles.

Now the skeptical may say that the latter action could not be an oversight but was part of an intended process to get certificates issued that would then be allowed for "someone" to monitor all google traffic coming from the domain, including secured gmail traffic. It certainly is possible that this was the case but it is obvious as well that proper process was not followed and if the process was properly audited then this would have been caught. The things that never should have happened:

Test profiles loaded into a production environment - this is easily solved through proper checking of server identification and not crossing platforms with profile files
Generation of production certificates using test profiles - should not happen as the production system RAs should not even have test profile names available for choice.
No audit checks - once any error of issuance is discovered all issuance logs should be checked and all issuance verified to ensure all issuance was accomplished per policy.

Now it is one thing for us to talk about what Turktrust did wrong but the reality of the situation is that we, as users and relying parties, need to be able to ensure that no matter if it was a set of errors or if it was an intended process to create a backdoor to the Google channel we need to be able to mitigate our risk. What this means is that we need to be able to quickly identify where we have certificates that may be at risk, whether that be in web servers, browsers, root store, local Java stores, in routers, VPN devices, network devices, or anywhere else. Personally I went through and double checked my new Android Jelly Bean install to make sure I was comfortable with its root stores. For organizations however this is a larger task and looking at systems that monitor and manage your certificates is an easy and important way to mitigate risk and one that seems to be getting more and more critical given the number of types of certificate attacks that are appearing.

Finally - this is not a "do not use certificates" or "CA providers are bad" type message - this is a "Take responsibility for your environment ... know who you trust and why ... and ensure that you understand when and why things change by monitoring the environment" message.

Maybe that last part is a good New Years resolution.

"But I wasn't a target!"

noreply@blogger.com (tricdn) — Mon, 17 Dec 2012 17:12:00 +0000

Being the father of 3 kids I frequently heard the refrain ... "It wasn't me". Quite often that was an accurate statement but every now and then ..... Whether it was Thing 1 or Thing 2 (or quite often Thing 3) it really did not matter - it happened and someone or something was injured in the process. The injury may have even been a side effect - the ball tossed - the catch missed - the glass knocked over or the eye hit. Not intentional but it happened.

In today's world of malware and cyber-warfare, attacks and spying, denial-of-service and data ransoming it is also true that you may not be the one being attacked but you may very well end up being a victim. This was the case of Chevron who recently found Stuxnet in their network. Now their investigation has not indicated any damage done but the fact that it was found in their network highlights the importance of being aware of not just what is in your network but also what is going on around you.

We have already talked about the concerns with malware that has been repurposed. What we are talking about in the Chevron case is malware gone wild. In either case knowing what is being successfully used as attack vectors is critical for corporate IT personnel to be aware and to some extent understand so that they can implement processes to properly begin to mitigate the risk. You may not be a target but you may end up being a victim.

Of course being a victim is more than just ending up with malware on your system. If you are using a service provider for any services you may end up being a victim if their infrastructure falls victim to an attack, either direct or indirect.

In any of these cases it all goes back to planning. Have appropriate business continuity plans. Not just plans to ensure services are properly configured and tested but plans that allow for restoration and if needed moving of services and data. Test these plans at least annually. Have service level agreements in place that encourage safe continuity of operations practices with your service providers. Ensure you have tools that monitor your infrastructure to be aware of any potential gaps that need to be addressed and to ensure that changes to one element of the infrastructure do not impact other elements. A common one is when an IT organization or application updates an SSL certificate but the business application owners are not aware of it. The application stops working and the application owners spend countless hours trying to determine the root cause. These types of situations highlight the need for plans to be broad enough to cover not just the infrastructure but the actual important elements of continuity of operations. Your tools should reflect this as well.

This type of planning will allow you to mitigate the risks that are increasing each and every day and will allow you to prevent or at least minimize downtimes.

Sandy Takes its Toll ... But also on our Confidence?

noreply@blogger.com (tricdn) — Wed, 31 Oct 2012 17:12:00 +0000

As you can tell from my last few posts I have had a renewed interest in the critical infrastructure area and in particular how proper planning is a significant element of being prepared. Super-storm Sandy brought home some of those ideas. For many of us on the east coast we had not faced such a major storm. Here in the DC area we were lucky that we had but a glancing blow. Our friends further up the coast were much less lucky.

Certainly we can never be fully prepared for something as rare as Sandy but there are lessons we can pull from the last couple of days and I am sure there will be many more we can pull from the next few weeks. I did read an interesting article from the NY Times this morning that is related to thoughts on planning and a few items in particular stuck in my head.

I have talked about critical infrastructure as a "system of systems", tightly interwoven in some cases and in others loosely connected. One sentence from the article relates to this;

"As more of life moves online, damage to critical Internet systems affect more of the economy, and disasters like Hurricane Sandy reveal vulnerabilities from the sometimes ad hoc organization of computer networks."

Much like the interconnected systems of gas, electrical, transportation, finance, telecommunications and others, the Internet arose from the interconnection of very different systems which were built for very different reasons. As Internet services grew so did the companies that provide services and this in turn led to elements of geographic disbursement of capabilities and further interconnectedness through telecom systems and power systems. This growth naturally means greater opportunity for interruption based on the fact that the target space is greater. Of course, in theory it also means greater opportunity for high availability and reliability but that only works when the specific service is built with that in mind. The moral here is that one needs to ensure that the services that you pick at least meet the reliability needs of the service that you offer.

Another item that jumped out at me was raised in relation to the power situation.

"Power is the primary worry, since an abrupt network shutdown can destroy data, but problems can also stem from something as simple as not keeping a crisis plan updated."

So when should a crisis plan be updated? Certainly it is something that should be looked at annually to ensure that the plan itself is inline with business needs but awareness of the environment you are operating in should also cause one to consider if the situational environment will have an impact on business. Is a hurricane ,or some other naturally occurring but foreseeable event, bearing down on facilities that you rely on, whether they are your own or those of service providers? Has the geopolitical climate changed whereby the threat of cyber- or physical terrorism against a facility becoming a more significant risk? These are just some examples of situations that should have you pulling out your crisis plan to ensure that the plan does not need to be updated or altered.

Finally there was one element in this article that demonstrates the need for planning.

"Another downtown building ... had one generator in the basement, which was damaged by water. There is another generator, but it is on a higher floor. ... “We’ve got a truck full of diesel pulled up to the building, and now we’re trying to figure out how to get fuel up to the 19th floor.”"

It was great that they had planned for two generator but a 19th floor backup without a plan for getting the fuel to where it needs to be? When thinking about your plan do not overlook the little things. It is great to have redundancy but if the redundancy is reliant on other systems then make sure you are aware of that and have plans to address any potential gaps.

All of these ideas are ones raised due to a very rare and dramatic event but the underlying principles are the same whether it is physical infrastructure or cyber infrastructure:

Understand the business needs for operations in regular and emergency circumstances
Understand the assets that you are reliant on and classify them into ones you have control of and those that are outsourced
Create a Crisis Plan and test it to ensure it meets the business needs and is executable
Review the plan on a regular basis and when significant events occur ensure to consider the impact on the plan

Know what you have, know what you need, monitor to ensure steady state and be prepared for events that disrupt the steady state.

Will Flame Scorch US Utilities?

noreply@blogger.com (tricdn) — Thu, 25 Oct 2012 16:15:00 +0000

Over the past couple of months I have spent a good deal of my time speaking to utilities, companies that work with utilities and attending conferences surrounding the utility industry. This has all been done in conjunction with the work that I have been doing in cyber-security over the last 20+ years. It has been an interesting couple of months as it has been a re-introduction into the whole idea of Critical Infrastructure Protection (CIP), which was one of the areas I was focused on a decade ago, but also has allowed me to link together some of the interesting aspects of what has been happening in the last two years, in regards to cyber-attacks, with CIP.

There has been lots of conjecture as to attacks against the US utility infrastructure, and in fact ample evidence that there have been breaches at varying levels and with varying effects. I am not going to go down the path of highlighting these as you can do the web searches that will help you find them. Yes some of them are real, and based on some recent conversations, some of the ones that were "Not cyber-attacks" were very likely exactly that. The bottom line is that the utility infrastructure is vulnerable and we need to do a beter job of detecting and reacting to these vulnerabilities.

Now all that being said there is another side to this puzzle. Everyone has heard about Stuxnet and Flame. You can read past posts to get a refresher. I have even discussed what I feel is the most worrisome element of these, which is re-use. We have already seen some of that within the payloads of these systems themselves. We are seeing more of that in other payloads being used for similar purposes including a "mini-" Flame that has been identified in the Middle East. The worrisome element here is not that the guys who created these are re-using elements but the fact that others are also re-using elements. Elements of Stuxnet have been found in recent financial targeted malware. Elements of Flame were seen in the attack against Aramco, the most valuable company in the world that also suffered the broadest attack to date.

The Aramco attack should be the red flag for many, or at least I hope. What Aramco showed is a couple of things:

The insider threat is real. The recent Verizon 2012 DBIR highlights the threat to IP from the insider threat along with the rise of hacktivism which seems to be another element of the attack
Malware does not die, nor do its delivery mechanisms. Both of these elements continue to live for a long time - they just evolve.
If your business is supporting cyber warfare then make sure you, and your allies, are aware of the re-use capabilities of code so you and your allies are not bitten back.

So how does all of this tie into US utilities? Well Aramco did show us another thing - that there are those that are unfriendly to the US and its allies and they have capabilities which can deliver harm. They may need help to do it but leveraging the code re-use elements and the hacktivism that exists everywhere today creates a risk for all utilities and other large sectors of the Critical Infrastructure that we need to pay attention to so we can mitigate those risks. The utility sector does create some additional concern as the past idea of utility security has been to build an "impenetrable" wall around the systems since the systems themselves were designed before the threats of 21st century cyber-capabilities were known. The issue they face today is that once someone gets through the door, into that secure environment, the damage can be swift and extensive, as evidenced in Aramco. Ensuring that organizations mitigate the risk by understanding their environment, the resources that they must manage and how their systems securely interact with others, inside and outside their domain, are critical to protecting the overall infrastructure.

Attack Elements Showing Up Elsewhere

noreply@blogger.com (Gary) — Thu, 20 Sep 2012 13:47:00 +0000

So it was a few weeks back that I had last posted on the rash of newly discovered attacks, their methods and payloads. One of the cautions I had tried to raise over the summer is that even though many people said that this was a specific attack, targeted at specific environments and that major vendors like Microsoft had reacted to shutdown the certificate based threat, that there was still a risk.
The risk i brought up was the risk that cyber criminals would take the basis of these attacks as a "cookbook" of types that would allow them to launch similar types of attacks on a whole new set of users. Today I came across an article published by MIT that confirmed my concern. The article highlighted that cyber criminals are using code from Stuxnet in attacks today and that the design of Flame makes it an even more attractive target for use because of its modular design.

So while we may think these much discussed pieces of malware and attack mechanisms are no longer a threat we need to be diligent in following the research and understand what is being done with the code and how it is being reused.

- Posted using BlogPress from my iPad

For those that thought it was over ....

noreply@blogger.com (Gary) — Fri, 10 Aug 2012 16:01:00 +0000

June and July gave lots of opportunity for people to talk about Flame and I will bet all of you are tired of hearing about it - and I would say rightfully so. The reality is that Flame is not likely to affect you. I know a few people who will hate that line but it is the truth.

The TRUE reality is that the attacks vectors and malware elements are not used once and then discarded - and that is why we have a problem in the world of cybersecurity. People see the headlines about Sykipot and Flame and then see days later mitigation mechanisms and that they feel is the end of the story - it truly is not.

Sykipot had a number of variants that have done damage in the wild and they have been seen over many many months. Some would say that the similarities between Stuxnet, Duqu and Flame are indicative of malware reuse with some additions in the attack vectors.

Now we have another variant that leverages elements of Flame and attacks the financial sector and could also contain elements to attack other critical infrastructure elements. Read about Gauss here.

The Flame may be out, according to the pundits, but the embers are still causing havoc and you need to be aware that the attack vector used is a dangerous one and that you need to understand your infrastructure to protect against attack. The malware side of these attacks will eventually be signatured but until they are you need to stop allowing strangers in your networks. In previous posts I have given some basic guidance on what you need to do but it truly does start with understanding your infrastructure: managing the trust domains you use through the Root Certificate Authorities you trust; ensuring you have a strong policy for user authentication; and when using certificates as part of that have a good policy for key length, algorithms used and lifetimes and then manage them properly.

Those embers will burn as long as there is money to be made attacking other people so you need to protect yourself from getting burnt.

- Posted using BlogPress from my iPad

Is Power Grid security being given up for convenience?

noreply@blogger.com (tricdn) — Fri, 20 Jul 2012 17:08:00 +0000

I live in an interesting area just outside of Washington DC. We have the suburbs that are old and established with the big beautiful oaks and then we have the growing suburbs that are sprouting out of old farm fields. The last few weeks have seen a rash of storms that have delivered devastating blows to the power supply at people's homes. Those in the newer suburbs have been less affected due to buried cable than those in the beautiful old neighborhoods where wire is still strung amongst those beautiful old oaks that tend to fall and take out the overhead infrastructure. Of course these storms are either summer thunderstorms, in this case, which happen during the hottest part of summer - so no power means no air conditioning in the DC heat. The other end of the spectrum is a nor'easter in February which takes out power when it is well below freezing. Welcome to living in the DC area.

Of course all of this has people talking about the power companies in terms of reliability and response. Things like "How can a company not be prepared for this type of situation - people without power for a week" have been heard frequently over the last two weeks. Well I am not one to beat up a power company for nature unleashing its fury. Nature is unpredictable and when a storm does happen, as in this case, it can be a very large undertaking to get things coordinated to remove trees and then restring wires etc.

Where I do have an issue is when it comes to the things that they are doing which can be planned for over a long period of time. We have all seen recent articles on the hacking of the power grid in various magazines over the last few years. In c|net, Scientific American, and you can even go to YouTube to see a video on how to do it. Congress, the National Security Agency and others have highlighted the fact that we have this vulnerability. The National Institute of Standards and Technology (NIST) has been working with industry to develop a stronger set of security standards for the SmartGrid to try and build a better grid.

BUT .....

We still have people in the industry that appear to think that the problem is not that bad. The North American Energy Standards Board (NAESB) authorizes two organizations to issue certificates for the Grid today - Open Access Technology International (OATI) and GlobalSign (Yes the same folks who had their website hacked earlier this year). Both OATI and GlobalSign feel it is OK to have long life certificates within the infrastructure protecting the power grid. In fact both have stated that 30 year certificate lifetimes are ok from a security perspective.

I myself find that amazing as the criticality of this infrastructure and its impact on Defense, Homeland Security and the economy is well recognized. This is an infrastructure you want to protect. Part of the argument is the difficulty in updating but then the OATI webCares CPS indicates an 8 year lifetime for Root certificates. Globalsign does allow 30 and 40 year Root certificates in its Certificate Policy and goes as far as 5 year for end devices. They also allow SHA1 hashed certificates, with a 2048 RSA key. There does seem to be some contradiction in the Globalsign CP in that it indicates following of NIST guidance but is not all that specific on which guidance. Certainly today NIST does not recommend use of SHA1 for any certificate use and long life certificates for Root CA's or any issuing CA is also not recommended due to the rapidly evolving attack vectors.

So what we are left with is two companies that seem to think that they can mitigate the risk of technology obsolescence. If we look at history we learn some very hard lessons. MD5 went from a suspected problem (1997) to a demonstrated attack in 8 years. Within 7 years of this first demonstrated attack (2005) there was a usable attack vector that allowed an attacker to introduce malware without the victim knowing and apparently not knowing for a couple of years. So yes one can replace their certificates if someone sees an attack against the CA or the technology that was being used but will that be too late? Will the logic bombs already be in place? If they are can we find them in time? If we do not what will happen? And what is being attacked, industrial control systems, have been targeted very recently due to existing vulnerabilities.

The risks are high here so rather than playing with convenience should NAESB not make it simple for all involved and strengthen these standards to reduce the risk? I would hope that if I asked the folks that went without air conditioning for a week in 100 degree heat if they would risk losing power again, and maybe for much longer, that they would react strongly. I wonder how people in hospitals and Wall Street would see things?

Flame is STILL burning

noreply@blogger.com (Gary) — Fri, 13 Jul 2012 13:13:00 +0000

In this case Flame continues to burn Microsoft. Microsoft have announced the termination of trust of 28 additional certificates within their infrastructure in addition to the 3 that were immediately untrusted when Flame was first brought to light. This new announcement is significant as it highlights the importance of certificates within an enterprise as large as Microsoft but also highlights the interconnectedness of systems. Microsoft's announcement was based on their believe that the newly untrusted CA's are "… outside our recommended secure storage practices". What exactly that means is certainly up for discussion but Microsoft itself states that this effort is being undertaken after their continued review of what happened with Flame. This likely means that they these certificates were protected only as well as those known to be compromised and based on the form of attack there is some level of certainty that these could be exploited as well.

This interconnectivity of systems is becoming a key element of security management. When I speak of interconnectivity I do not just mean network connectivity but I also mean trust connectivity. With todays growing base of interconnected devices, whether that is the traditional server/desktop/laptop, the simple extension to mobile devices such as smartphones/tablets, or whether we take it the next level to control systems such as those interconnected through networks such as the SmartGrid or ones run by companies such as Tridium, we need to consider what happens when a security gap in one element of that infrastructure exists.

This, of course, is also not the end of the conversation. Even if we can find all those certificates and systems that Microsoft "untrusted" on all the platforms that we own and manage, this is one example of how the use of a vulnerable algorithm can create a significant and broadly impacting issue. We knew MD5, the hashing algorithm that was exploited in the original attack, was vulnerable in 2005. In fact some would rightfully argue that we knew about it almost a decade before that when flaws in the algorithm were first identified. At the time these flaws were not considered catastrophic but between 2005 and 2008 attacks against MD5 were demonstrated multiple times. It was so well understood at the time that Microsoft published a recommendation not to use MD5. In 2009 though Microsoft issued a new CA certificate using MD5. A mistake on their part but one that got through and created a significant problem.

MD5 is not the only vulnerable algorithm. Other elements of the system are also vulnerable, thankfully just not exploited yet. These other areas include one of the most commonly used hashing algorithm, SHA1, which has been theoretically shown to have a vulnerability (recognized by NIST in early 2005) but no known attacks have been shown. However the National Institute of Standards and Technology (NIST), which provides guidance for the US Government on computer security requirements, published in 2004 that SHA-1 be phased out of use in the US Government beginning in 2010. The phase out is intended to be completed by the end of 2012.

Hashing algorithms are not the only weakness. Based on the strength and availability of computing systems, 80-bit cryptography is considered vulnerable. Of course everyone will say that they do not use 80 bit keys but what NIST is saying is that algorithms with certain key sizes only provide effective security strength of 80 bits. This includes RSA-1024, DSA-1024 (with specific characteristics) and Elliptic Curve where keys are less than 224. The specific sizes of these three algorithms are again being phased out of use within the US Government as they are considered vulnerable for their common purpose. They will be completely phased out by 2013.

So yes Flame did turn up the heat on Microsoft but it also raises the overall issue of technical obsolescence of cryptographic algorithms and key sizes. This is not the first time this has happened but the major difference is that today the problem is bigger due to the interconnectedness of the systems. We now need to consider how to mitigate the threat posed here and this is where we can learn something from Flame. Flame was created as a data gatherer – the old adage of "know your enemy". We need to do the same thing and in this case the enemy is the use of vulnerable cryptographic algorithms and key sizes. Assess your environment to determine what is used and why and plan to replace those algorithms and those certificates built around vulnerable algorithms as quickly as possible.

And for those of you that think Flame is not an issue - take a look at some of my recent posts and as you read them think about Sykipot and how that has evolved over the last year. Workable exploits do not die - they evolve as our defenses do.

- Posted using BlogPress from my iPad

Do you want to be scared?

noreply@blogger.com (tricdn) — Tue, 03 Jul 2012 21:04:00 +0000

In 25 plus years of working in the data comm industry and the majority of that working in the cybersecurity/data security realm I have diligently stayed away from fear-mongering. My basic approach was that there are plenty of business reasons to take cybersecurity seriously, whether it was to maintain your control of your investment, stay ahead of your competition, perform tasks more efficiently, reduce costs of shipping, paper, manpower, and many other benefits. There never has been a reason, from my perspective, to dangle the scythe of death over anyone's head.

Now there have been times when I have looked at cybersecurity from the scythe of death perspective. A number of years ago I worked with the US Government on Critical Infrastructure Protection and there you need to look at cybersecurity from that perspective because if you get it wrong very bad things can happen. So over the last few weeks with all of the discussion on Flame and its relation to Stuxnet and other attacks I started to look at what does this mean from the bigger cybersecurity perspective.

Lots of people hear about these malware variants and when you talk to them their first response is "That won't affect me - it was targeted at Iran" or other Middle Eastern countries. The latter part of that statement is certainly true ... but .... let me pull out the scythe here. What Flame and Stuxnet ended up doing was writing a new chapter in the cyber-attackers handbook. Certainly the creators did not intend for this but through some carelessness the Pandora's box of cyber-warfare has been opened and in it is a very powerful toolkit. Note I did not say weapon. What Flame and Stuxnet has provided is an approach to attacks that is unique and inherently difficult to recognize. Certainly there are tools out there today that can recognize malware that is known about but what Flame and Stuxnet introduce is a way to use the inherent trust of the Internet architecture to allow the introduction of malware to your environment that may not be discovered through those normal processes and checks.

Think of it this way - today people get upset when they discover that you can go on the web and find the "How to make a pipe bomb" instructions. What if you could find the same instructions for a nuclear weapon that was undetectable? A weapon that could be delivered to any city without anyone knowing about it because you inherently trusted the way it was being delivered and there were no tests to check against it? A scary proposition - but potentially not as catastrophic as what can be done with a Stuxnet like attack using the Flame approach to delivery. Think of what could happen if operators could not control the power grid, the water supply chemical composition, the natural gas pipelines or potentially the mechanisms used to transfer funds between banks and brokerage houses. Now imagine that all of those things went wrong on the same day. That is cyber warfare and that is the handbook that can be written with the existing toolkits that are out there today.

But, that is the worst case scenario and things can be done to mitigate the risk. The National Institute of Standards and Technology (NIST) publishes documents which describe the appropriate ways to protect data including what algorithms to use and what policies to have in place. These include things like using appropriate crypto and avoiding algorithms with known weaknesses. Flame took advantage of the fact that not everyone is following these guidelines and for that attack they were able to spoof a Microsoft certificate that used an MD5 hashing algorithm.

So if you want to mitigate some risk look at what NIST has published (start at csrc.nist.gov) to see if there are things you can do better. And remember what one of my colleagues said after Flame was better studied ...

"Friends don't let friends sign with MD5"

... Tim Sawyer

If you want an interesting look at a piece CBS 60 Minutes did on this topic then check out this video.

Collaboration - Walk into any partnership with open eyes

noreply@blogger.com (Gary) — Wed, 20 Jun 2012 14:52:00 +0000

The title of this blog may seem to have little to do with security at first glance but the thought came to me as I continue to follow the developments in the Flame arena.

As always the discussion here is based on information that we know. There is always a chance that what we know has been planted so always consider this when planning actions - and I guess that ties into the whole point of this post.

I was reading an item on Flame that seemed to confirm some of the original thinking, that the recently found incarnation is directly related to the development of Stuxnet as well as Duqu (and likely others). This should not be earth shattering to anyone as the pointers to that linkage are many including shared code, common targets and when looking at the bigger picture the fact that Flame was a data gatherer while Stuxnet included action elements. This follows the "know your enemy before acting" mentality.

The interesting thing for both Stuxnet and Flame is that discovery came only after one of the collaborators in developing the platform decided to take action with the platform outside the original scope. Stuxnet was discovered when it went beyond its target platforms and into the Internet after a poorly implemented code change. It now appears Flame was discovered after it was directed to another environment. Both these actions were unilateral actions taken by one of the parties involved in the development.

These types of actions should not surprise anyone either. When you have a vehicle such as this that has been successful for a period of time the temptation to manipulate it for your benefit is significant. What we need to think about though is the impact it had on the overall program. Did these actions raise the risk of other similar platforms being discovered or other actions being taken to reduce risk? Does this now impact how successful the original program is going to be in halting or delaying the original intent? We need to remember the goal here is to halt or delay nuclear weapons development so the stakes are high.

But in the general business environment the same thing can happen. I am not suggesting you cannot have good partnerships between companies that are "frenemies" but you do need to make sure your eyes are open. Of course it is more than just redirecting the partnership - when companies collaborate you also need to make sure that the shared environment is protected to the highest common denominator of security. It is no longer just our data at risk - it is also your collaborator's data and that loss could pose bigger problems in the long run.

It appears that the Stuxnet-Duqu-Flame attacks has brought to light more issues than just the security issues. Yes those security issues are many including very important ones like managing your trust environment and evaluating what certificates and algorithms are in use and/or trusted in your environment, but we now also need to consider that this effort really became known only because of mistakes made by one partner in the trust relationship. That may be the bigger lesson - security is not just about what you do but also what those that you deal with do as well.

That is something to spend some time thinking about.

- Posted using BlogPress from my iPad

Flame Extinguished?

noreply@blogger.com (tricdn) — Fri, 08 Jun 2012 20:21:00 +0000

I will give Microsoft credit in reacting quickly to Flame and its use of faked Microsoft CA certificates. Microsoft quickly came out and moved the two MD5 certificates that were faked and the SHA1 certificate that was abused to its untrusted store. The fact that they did this through the Microsoft update, which was one of the transaction sets that was hijacked by these certs, is kind of funny but that is an aside.

So did Microsoft solve the problem. The simple answer is NO!

Microsoft solved the problem that was created by their certificates. The problem that was created by generating a CA certificate and having the signature applied using an algorithm that was known to have weaknesses and was demonstrated to be attacked in a very similar way the year BEFORE the certificate was generated. In putting their certs in the untrusted store they closed this door - but this is not the only door that exists.

What Flame did was highlight that this attack is not only feasible but something that is executable. Did this take a high degree of knowledge and expertise - of course. The MD5 attack was a bit different then that demonstrated in the past - but this was something that was going to happen. The original demonstration of an MD5 collision attack was done on a cluster of high-end IBM UNIX servers. A few short years later the attack was performed on a network of 200 Playstation 3s. Now this says a lot about technological advancement in processing power for sure but also says a lot about the threat and how rapidly it grows. In 2005 when this was an active topic Ron Rivest (the R of RSA) said ""md5 and sha1 are both clearly broken", when speaking in terms of collision resistance.

So what do we take away from this? Organizations, including groups like the CA Browser Forum, need to get very diligent about what CA certificates are in browsers, applications, and hardware devices. These need to be assessed for requirement, strength and validity periods and a clear strategy needs to be put in place to understand what is there and how to replace what should not be there. If you look in your out-of-the-box browser today you will not only find MD5 based signatures but also MD2 based signatures. Yes these have been around for some time but we must think that if they have been replaced with a new infrastructure why are we keeping the old ones around? We must also start to question the lifetime of the SHA1 based signatures. There are some CA certificates that are out there that are SHA1 with very long lifetimes - and some with weak key algorithms (RSA-1024 keys for example).

So it is time to get diligent and start to manage your environments - or the next flame may be one licking at your feet.