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.

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.

M2M Making Buildings for Greener

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

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

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:

1. Know what is in your network when it comes to the trust infrastructure. This means:
1. Know what certificates and keys are being used and why
2. Ensure that cryptographic assets that are used in your environment meet your policy for strength, lifetime and algorithmic uses
3. Ensure every cryptographic asset has an owner assigned to it and that you can keep that data up to date
2. 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.
3. 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

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

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

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

"But I wasn't a target!"

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?

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.

Where do I start looking?

This past weekend I was lucky enough to get to hear some great conversations and presentations. It was part of my company's (Entrust) annual conference. The many conversations were with colleagues, partners and customers. The presentations that stood out were from customers, all saying what wonderful things we have done to help them but two in particular stand out that were more general. These two were talks given by Michael Chertoff (former head of DHS) and John Adams (former head of CSE, sort of NSA in Canada for those that need a basic explanation of CSE). Both men have a wonderful breadth of experience and a great view of what is needed to help protect the nations better.

Both men presented an interesting view of things and they certainly have the experience to be able to support their views. Their stories of how things were uncovered are beyond entertaining - the stories truly are frightening when it comes to what could have happened.

Given their experiences in very different environments they did have fairly common views as to what is needed:
- mitigation is key
- layering security is critical to achieve this
- there is no silver bullet
- you cannot protect the network - you must protect the data
- identity is single most valuable asset
- security challenges start with the individual

When one starts to look at these elements it can be broken down to items that apply specifically to businesses but also items that carry across both business and individuals. One important element of that is education. We need to do a better job of educating people with the elements of security that they need to be aware of and address themselves. We do this fairly well in medium to large businesses as to how they protect data with strong passwords and changing them often; keeping security software current; and managing patch updates. What we do not consistently do is to carry those ideas to end users in their homes. End users should not be using the same userid and password on all accounts. Grades of passwords are an effective way of reducing risk. One view that was shared was that 80% of security issues can be addressed by patch and password management. I am not sure that is measurable but certainly we could mitigate a lot of elements with these guidelines.

To re-enforce the above idea, in his discussion former Secretary Chertoff presented an interesting analogy - for some environments security is like an M&M - it has a hard shell but some soft, good eating on the inside. This goes directly to the idea that if users do not effectively manage their security they can create this false sense of security. "I have Microsoft Security Essentials - I am good". This view certainly does not address the password breach issue.

The idea of common userid/passwords across multiple applications at different assurance levels also challenges the implementation of your identity as your most valuable asset. Today too many of us use our email address and password as the login mechanism for a variety of applications, including things like online shopping, access to medical records and other applications. This opens users to phishing attacks that expose more than just access to email accounts but also to this potentially sensitive and possibly damaging information. We need to do a better job at making people aware of these things.

So the title of this post was "Where do I start looking?". Well maybe we need to start with looking at what we do ourselves and how we teach our children and friends about what is important to do when it comes to computer security. I know my kids are aware - are yours?

- Posted using BlogPress from my iPad

Location:Ellis St,San Francisco,United States

Looks Can be Deceiving ....

One of the issues I personally run into is walking into a new environment and people asking me about my experience. The issue, or so I am told, is that I look young for my age. The problem this creates is that when I state that I have 25 years of experience in the secure data world people begin to wonder if I am overstating things or intentionally inflating them. No the reality is I am progressing in age and my college age kids will attest to that. I just seem to be gifted with good genes.

Now what does that have to do with security and identity. Well for those that have been around I think it will be obvious - things are not always what they seem. "That cant't be - it's too good to be true" "Really you saw that online?" are just different ways of saying the same thing. Security is about diligence. In my example the customers are being diligent, they are making sure they are getting what they paid for. In these other cases - it is quite likely someone will get what they deserve if they were not diligent.

In the corporate and government security world we try to make diligence programmatic. We black or white list things. We take out what is bad or we close everything down and open up what meets the security requirements and need. We define policy and practices to adhere to. We have firewalls, intrusion detection, intrusion prevention, virus scanners and on and on. But we still need to remember we have people involved.

In the past year we have had lots of cases where the person was the problem - a Citi exec charged with wire fraud and UBS and Countrywide execs also charged or sentenced. The lesson from these is broader than just the specific financial mess that falls out but it is a lesson of diligence and oversight. It is a lesson of education. These are lessons that equally apply in building a security plan. No matter how good the technology and policy it these things have to get implemented. And that implementation needs to be done by well trained people with appropriate oversight dependent upon the associated risk profile.

Is the sky really falling on the security world?

One has to wonder if this is the year when someone mentions security and we get a collective guffaw or is it truly a case of people are starting to pay real attention. I like to believe the latter but then I see article from Dark Reading on an Ernst & Young Report "Security is Still an Afterthought..." and I am not sure. Certainly attention in the media can be a good thing in that it should get people thinking. I certainly start thinking when I see news of breaches, attacks or vulnerabilities - "Do I have to worry about my environments?" "Is this an opportunity to share knowledge?" or "Is this an opportunity to look at a system differently?". Part of the issue I have with the coverage though is that there is usually the sensationalist article "<insert technology here> is Broken" and it gets mainstream attention and explaining to people the real story then takes lots of time.

Experience has taught me that it is not always a case of technology being broken. Now grant it we have had those cases but generally speaking what we have seen lately is not technology being broken but technology being poorly leveraged or poorly implemented. Lets take some examples:

- The RSA breach: Why was it as bad as it was? Well someone had left critical data on a networked computer. Is the RSA two factor solution a bad technology - NO! Did the implementation of their infrastructure  have some fundamental design/implementation issues - YES.
- The Comodo attack: Is PKI a broken technology - NO! Did Comodo miss some fundamental implementation rules be not having strong multi-factor authentication for their RAs and not having back-end checking for domain use during issuance - It certainly looks like it.
- BEAST: Is SSL/TLS a bad technical specification - fundamentally NO! Have browser, server and other vendors that leverage SSL/TLS done a good enough job in keeping abreast with updates based on enhancements to the specification - obviously NOT!

So what do we learn from this - yes we do need to pay attention to the press, whether it be a trusted blogger or trusted news source. The data that they deliver though is only one piece of the picture so we need to make sure we take that data, add to it and then assess what it means in our personal, corporate or organizational content.

It is an old adage but it is not just technology - you need to consider the people and process around it. That includes education, policy, implementation and all the other elements that make up a good security plan.

So CL you are safe - the sky is not falling - but make sure you are looking all around you and not just up - problems can come from any direction.

Those who cannot remember the past are condemned to repeat it

This quote from George Santayana has been somewhat skewed over time .... "Those who do not learn history are apt to repeat it" being one popular one but I believe Santayana's words are as true today as ever.

No this is not a post about politics - it is about security and ties into some of the recent thoughts on planning. As I had a coffee today I began to think about security from a network perspective. Not network security but the perspective of security being established through the interconnection of people, technology and events. As I did this I remembered some of my history and it then dawned on me the similarities of things in the past and what has been happening today. Let me try to explain.

Most of you are familiar with the Comodo attack from earlier this year. The attack was perpetrated by going after the platform used by an administrator. The success of this attack led the attacker to being able to create credentials in the name of some very significant companies that would have allowed very broad attacks on potentially hundreds of thousands of users. Thankfully the latter part of the attack was not executed and the breach was discovered before major widespread damage. The point here was that the attack was against the management plane of the system and an attack at that level can be hard to discover. A similar management plane attack occurred in 2010 that allowed someone to take control of a private Certificate Authority which caused major problems for a very large contracting firm in the US. Two examples of management plane attacks that created great havoc.

So where is the history linkage. Well 25 years ago there was a manager at a firm in California that discovered an accounting error in a system. He asked one of his people, Clifford, to look into this. It took some time but Cliff was able to discover a sophisticated attack against the burgeoning defense and other networks. He eventually traced the perpetrator to a network connection coming from Germany. For some time he got no where working with the Deutsch Bundespost, who ran the networks, and then one day they called with the data he needed. What Cliff did not know at the time was that the perpetrator had used a management plane attack within the Bundespost system. He was able to connect to the DBP network, carry out his attack against networks all throughout the US and then he would go back and delete the accounting record on the network switch before it was uploaded to the accounting system. To the DBP the user was never there. A young guy living in Ottawa worked with the DBP and they found the switch coding issue that allowed the guy to delete the accounting records. The hole was closed and a couple of months later Markus Hess was caught.

Now closing the accounting error at the DBP was only one piece of the puzzle, to learn the rest read The Cuckoo's Egg, but it did show that an attack against the management plane would provide a mechanism to hide the real attack.

The lessons learned here are many but the big ones - understand system connectivity (the network), plan to protect hierarchically making sure the high value management system gets attention, and leverage new technologies that provide strong two or three factor authentication on the highest value assets since a breach there will either bring the entire system down or will create a security gap that is not even known about.

- Posted using BlogPress from my iPad

Timely ....

A few weeks back I wrote a piece on planning. The context may have seemed odd to some, unless you are a runner, but the basic idea is that for any challenging undertaking you need to plan not just for completion but for events that may hinder that completion whether those events occur in the preparation or execution of your plan.

The timeliness aspect comes in light of a lot of recent articles and commentary around breaches, social engineering attacks and announced vulnerabilities. It should be no surprise that we are seeing an increase in articles on this with DefCon in Vegas this past weekend, and the events that lead up to it, but I think we are also seeing the recognition of a true problem even from outside of the technical community.

As I read some of the articles that come out I see a consistent theme - little opportunities that are missed that either created the gap that was taken advantage of or created a gap that made the initial event so much worse. One of the best pieces I have read that begins to address some of the issues with actionable ideas was a piece written by Jeffrey Carr on Shady Rat. In this piece he identifies a four step process that starts to address the "gap that made the initial event worse". This type of direct action taken conjunction with development or revisiting of a broader plan is what is needed for organizations big and small. (For those small organizations that think this is a non-issue take a look at the Anonymous hack at rural sheriff offices and that is the new stuff - the older stuff would really scare you)

What is that broader plan? I wrote on some of this a few weeks back and I still contend that it is bigger than this or any blog is, but there are some basics. I hate simple graphics as they can be so empty but I think in this case if we go beyond simple we are writing a book - so here goes:

For most organizations 5 simple areas are what is needed to be looked at. I was going to do the loop-back diagrams but being a car guy I like gears better and it gets the point across. The point is that all five elements need to work together. The four outer gears, although smaller, are as important to get right as the overall strategy. All these working together is what drives the organizations business purpose. Mess with one gear or implement it poorly and the overall plan suffers. As I mentioned a few weeks back, ignoring the surprises, or not being prepared to respond to the unknowns will also cost dearly.

I think that most companies will say that they have these basic elements in their plans but based on what is happening in in the real world we are seeing that either they are not well implemented or not being effectively updated and monitored. A plan is only as good as it's execution. So take a look at your plans, update them as needed and have in place a regular review - and that does not mean every 5 years. In today's world it should, at least, be part of your quarterly reviews.


- Posted using BlogPress from my iPad

Planning is important

This week is my last week of doing baseline running in getting prepped for the Marine Corps Marathon. Next week the real training plan kicks in. As I was doing a few miles the end of last week I had a long discussion with myself on the similarities between marathon training and security planning - and the glaring similarity is that you need a plan and you need to stick to it.

Everyone sees a marathon as 26.2 miles. Yes that is accurate but it is not the whole story. It does not talk about the weeks of planning and the months of 30 or 40 mile weeks that you are running. Those 26.2 miles do not talk about the tempo runs, the interval runs, nor the long distance runs. It does not talk about the handling of injuries, the planning for hydration and nutrition when running 16, 20 or 26.2 miles. Those are all details that get lost in the vision of a marathon.

Security planning is no different. There is no silver bullet in security planning. It is a long hard slog. Planning simply makes most events more controllable. Yes there will always be challenges, a breach due to a new zero-day attack or a true ATP, but the plan should also include how you handle these much like the marathon plan includes how you handle a strained muscle or a bad cold. Security planning needs to involve all relevant parties - business owners, CxOs, developers, hr, and where possible relying parties and end users. At least for relying parties and end users their needs and concerns need to be assessed and addressed. Security planning also is broad as well as deep. It is not enough to protect the boundaries, as we have all seen from recent attacks like those at the National Labs, but it must also consider subversive attacks. The plan must also involve things like: how I know who is entering my network; what happens when their means of authentication has to be challenged and how that happens; how do I detect attacks - on the periphery and inside the network; how do I control what hits a desktop - balancing between business function and protection; ad of course this list could go on for days worth of reading.

The point here is that it is the plan that is important - and that plan needs to be constantly assessed based on new needs, new data points, new attacks - and execution of the plan has to be the responsibility of one part of the organization with the assistance, cooperation and input from the others. Just like my marathon training plan, which does not succeed without a lot of help, input and support from my wife and kids, an organization security plan will not succeed without help and support from your organization and when needed some outside experts to give that independent view of how you are doing.