Sitting here in the Washington, DC area these days gives one much reason to ponder economics. As someone who has worked with the Government for over 15 years there is always the economic factor in the back of ones mind. Most people think that the government just buys things and the process is easy and straight forward. However this is generally not the case, especially when we talk technology. Programs need to be defined, planned, and budgeted. These budgets need to get into a budgetary cycle that can last 18 months and beyond and then budgets need to be passed. Even after that it is always possible that things change and 2011 has offered lots of opportunity for change.
Now you may ask what this has to do with the economics of security. Well we have all seen the numbers - and while they do vary they are significant. Data breaches are up over the last 5 years, and up substantially. Over the last couple of years the costs of these breaches has been up as well, with average cost increases per incident up somewhere around 15%. Average individual incident costs have been stated to be anywhere from 3-7 million dollars.
With this backdrop Congress has been working on a couple of new bills covering Data Security and Breach Notification. The work done here is to be applauded as it is a step in the right direction. The question becomes what happens to these efforts and other government security efforts as Congress moves to reduce spending?
It is correct that corporations and individuals need to be aware of risks and implement proper mitigation strategies but what happens to programs like NSTIC, which is advocating increasing personal security, and to legislation that defines oversight framework? Are bills that require action by industry and government effective without oversight and enforcement? On the other front what happens to government programs within agencies that are looking to improve security with the goal to reduce costs? There are numerous technical advancements that could reduce costs while improving security, such as moving from expensive radio systems within DOD to smartphone based systems. With the ability today to enable smartphones as strong authentication systems the technology can be more broadly deployed at lower costs than existing systems. The question is how does such an idea move forward if the funding is not there for it?
The goal here is to mitigate the new risks by improving the baseline systems. Improved authentication systems based on open standards; enhanced authorization systems that leverage existing standards and are interoperable; and leveraging validated COTS products are all ways to improve security while controlling costs. Will these get lost in today's new realities? I hope not. Seeing how an NFC enabled smartphone can be used to access multiple applications using a variety of authenticators, that is easy for a person to understand and use, will only improve the overall security posture and reduce the number of these breaches. And that is good for our economy.
- Posted using BlogPress from my iPad
Friday, July 29, 2011
Monday, July 25, 2011
Authentication Beyond the "Norm"
A week of vacation always gives one time to do some extra reading - catching up on things and looking at a broader base of things. This past week I had that opportunity and a theme came through in some of the articles I stumbled upon ... Authentication is generally thought of as a person authenticating to an application or two applications authenticating to allow processing of data. However there are other things that we need to keep in mind when we think of authentication.
Some of the major issues that are now being encountered are centering around source of base technology. Malicious code embedded in devices manufactured in other countries is one example. To date we have seen this method leveraged in devices used within the power grid and this has also been seen within components in laptops. This type of extended attack is much deeper and worrisome for many as it can go undetected for many years before being launched. Within the software application environment we of course have code signing that is intended to mitigate the similar style of attack which has been seen through code delivery. Code signing itself cannot stop the attacks that are further embedded in the base technology and to some extent does not mitigate all software based code attacks. There is a need in both environments to design a more complete end to end protection of systems.
Part of the issue in design of such systems comes to ensuring compliance in an environment where base technology is being delivered from many sources and in many cases to a consumer that is first concerned with immediate technological gratification - how many of us click through user agreements before installing software? Certainly there is an attempt at resolution here with the Trusted Computing Group's platform approach but broad acceptance of this across the many technology platforms has not happened.
So how do consumers and users protect themselves? That may be the muti-billion dollar question. Certainly there are simple things to mitigate risk for a consumer:
- Where possible buy a platform with a TPM (Trusted Platform Module)
- Only execute signed code
- Ensure proper validation options are turned on (CRL/Revocation Status checking for example)
The broader answer is something like TC. Is it signed object code? But how do you validate that code? Who authorizes the signature? Certainly there are many more questions and solutions but it is a problem that is growing and it will take a cooperative solution between hardware technology manufacturers, software distribution companies and software developers at a minimum. Education for the consumer is also important and something that has to be considered.
Maybe initiatives like NSTIC will get the conversation going - that would at least be a start.
Some of the major issues that are now being encountered are centering around source of base technology. Malicious code embedded in devices manufactured in other countries is one example. To date we have seen this method leveraged in devices used within the power grid and this has also been seen within components in laptops. This type of extended attack is much deeper and worrisome for many as it can go undetected for many years before being launched. Within the software application environment we of course have code signing that is intended to mitigate the similar style of attack which has been seen through code delivery. Code signing itself cannot stop the attacks that are further embedded in the base technology and to some extent does not mitigate all software based code attacks. There is a need in both environments to design a more complete end to end protection of systems.
Part of the issue in design of such systems comes to ensuring compliance in an environment where base technology is being delivered from many sources and in many cases to a consumer that is first concerned with immediate technological gratification - how many of us click through user agreements before installing software? Certainly there is an attempt at resolution here with the Trusted Computing Group's platform approach but broad acceptance of this across the many technology platforms has not happened.
So how do consumers and users protect themselves? That may be the muti-billion dollar question. Certainly there are simple things to mitigate risk for a consumer:
- Where possible buy a platform with a TPM (Trusted Platform Module)
- Only execute signed code
- Ensure proper validation options are turned on (CRL/Revocation Status checking for example)
The broader answer is something like TC. Is it signed object code? But how do you validate that code? Who authorizes the signature? Certainly there are many more questions and solutions but it is a problem that is growing and it will take a cooperative solution between hardware technology manufacturers, software distribution companies and software developers at a minimum. Education for the consumer is also important and something that has to be considered.
Maybe initiatives like NSTIC will get the conversation going - that would at least be a start.
Sunday, July 10, 2011
What is Security?
I read an interesting article this morning on mobile banking. Now do not get me wrong - I am looking forward to mobile banking but the article raised another question in my mind - what exactly is security?
There are lots of people around the world using mobile payments today. With the advent of Google Wallet, Serve, VISA Wallet, ISIS and others combined with the rollout of NFC enabled phones this will only grow. Of course as this begins to grow these companies will focus their attention on making sure that their systems cannot be breached. The last thing they need is someone to pay for something they did not buy or to have the bitCoins situation of suspected account breaches occur. The use of strong authentication and fraud detection improves the security posture and the retailers themselves are bound to protecting data to maintain their agreements with payment systems such as VISA and MasterCard, so one would say the system should be as secure as the payment systems in use today.
But is it truly a secure system? The WSJ article discusses one of the big concerns that came out of the NSTIC privacy conference - reuse of data. What information is the payment system I am using or the retailer I am dealing with collecting? How are they using this? If a retailer collects my cell phone number as part of the authentication process can they keep that data tied to what I bought and the next time I walk near their store text me a coupon? That of course is the most minor case here.
This is yet another demonstration of the need for privacy controls at the device and within the relying party. At the device it should come as a form of an information or attribute release option, defaulted for some transaction types and interactive for others. At the relying party, in this case retailer, some form of opt-in mechanism for data handling. Maybe I want the coupons - but give me the option.
So is a system secure if the user does not have control of their privacy or is it good enough to say that the system will not have a serious breach? It is a interesting question.
As can be seen there are still lots of areas of specifications that need to happen. Are these areas for policy definition within something like PCI or are the areas here something that need to be included in legislative discussions? Lots to be done and how it happens, I believe, will determine how successful these systems are.
- Posted using BlogPress from my iPad
There are lots of people around the world using mobile payments today. With the advent of Google Wallet, Serve, VISA Wallet, ISIS and others combined with the rollout of NFC enabled phones this will only grow. Of course as this begins to grow these companies will focus their attention on making sure that their systems cannot be breached. The last thing they need is someone to pay for something they did not buy or to have the bitCoins situation of suspected account breaches occur. The use of strong authentication and fraud detection improves the security posture and the retailers themselves are bound to protecting data to maintain their agreements with payment systems such as VISA and MasterCard, so one would say the system should be as secure as the payment systems in use today.
But is it truly a secure system? The WSJ article discusses one of the big concerns that came out of the NSTIC privacy conference - reuse of data. What information is the payment system I am using or the retailer I am dealing with collecting? How are they using this? If a retailer collects my cell phone number as part of the authentication process can they keep that data tied to what I bought and the next time I walk near their store text me a coupon? That of course is the most minor case here.
This is yet another demonstration of the need for privacy controls at the device and within the relying party. At the device it should come as a form of an information or attribute release option, defaulted for some transaction types and interactive for others. At the relying party, in this case retailer, some form of opt-in mechanism for data handling. Maybe I want the coupons - but give me the option.
So is a system secure if the user does not have control of their privacy or is it good enough to say that the system will not have a serious breach? It is a interesting question.
As can be seen there are still lots of areas of specifications that need to happen. Are these areas for policy definition within something like PCI or are the areas here something that need to be included in legislative discussions? Lots to be done and how it happens, I believe, will determine how successful these systems are.
- Posted using BlogPress from my iPad
Wednesday, July 6, 2011
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.
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.
Subscribe to:
Posts (Atom)