• The certification is static. In other words, there is a configuration at a given time, with a given product build, which is certified. The next hotfix or update basically invalidates the certification and you run the product rarely in the configuration certified. We make all the policies and configuration public – if you want to use them, feel free.
• It is slow. Even though we have plenty of experience by now, it still takes us more than 12 months to get a product certified.
• It is expensive. I will not go into the details here but it costs us a lot of money. This is the cost of doing business, I get that but there has to be a better way to address this.
• Typically the protection profile certified against does not completely meet the customer’s requirements. This means a lot of additional energy by the customer and us to go the final mile. This leads, unfortunately, to local requirements, local certifications and accreditations. Again, cost of doing business.

Being an engineer, I am deeply convinced that a secure product is the result of a sound and strong process embedding security into the lifecycle from the beginning. I am convinced as well, that product certification gives you a certain level of assurance but not too much. The process would probably give you much, much more to build your risk management on.

At the Security Development Conference this week, we declared conformance with ISO 27034-1, the first part of a standard on secure software development. Here is the official statement:

Microsoft has used a risk based approach to guide software security investments through a program of continuous improvement and processes since the Security Development Lifecycle (SDL) became a company-wide mandatory policy in 2004. In 2012, Microsoft used ISO/IEC 27034-1, an international application security standard as a baseline to evaluate mandatory engineering policies, standards, and procedures along with their supporting people, processes, and tools.

All current mandatory application security related policies, standards, and procedures along with their supporting people, processes, and tools meet or exceed the guidance in ISO/IEC 27034-1 as published in 2011.

Basically, this means that we are convinced that our Security Development Lifecycle fulfills ISO 27034-1. Transparency in this context is absolutely key in my opinion – much more than any product certification or any statement along the lines of “we trust our (fill in a role), he/she is in the business for so long, he/she knows what to do”. No joke, I heard this statement more than once.

In the future – and in the Cloud – transparency how software is built and ultimately run, how a company does incident response etc. gains more and more importance. Looking into the purchasing processes of our customers, they are still much too much focused on the product itself, in my humble opinion. I am convinced that this should change and should change rapidly.

If I may give you an advice: If you do not want to rely on a relatively new standard, you might just start by asking your vendors about how they develop software, how they react on incidents and product vulnerabilities, what support you get when you get compromised on their platform and – if you move to the Cloud – how they run your environment. Use your common sense before any standard when you judge their answers and see what the outcome is. I did it more than once and the answers are amazing (not to the good fairly often)

Roger

Related articles

• Microsoft declares conformance with ISO 27034-1 (computerweekly.com)
• Microsoft Commits to Secure Coding Standard (cio.com)
• Microsoft commits to secure coding standard (networkworld.com)
• Microsoft commits to secure coding standard (techworld.com.au)
• Microsoft commits to secure coding standard (computerworld.co.nz)

Where are we today? We all talk of Consumerization of IT (CoIT), we talk of “Bring Your Own Device” (BYOD) – but the mindset in a lot of companies did not change at all. They run projects on BYOD and define a set of acceptable hardware models – which is outdated the moment they publish it as it takes them a few months. I think we need to change our approach as the world changed. We need to think “policy and requirements” and not “hardware models and OS builds”. We might decide in a security policy that we require a device to be allowed access to sensitive resources to have a TPM chip to protect the keys. We might require disk encryption to be switched on (Bitlocker with TPM in our case). We might require IPSec policies to be deployed to authenticate the device to the server. We might require full patching etc. etc. But why the hardware? We might care regarding support but if I bring my own device, hardware issues are my problem, aren’t they? As long as this is clear, we can head that way and still offer supported hardware with a standard build to people who want to get full internal service.

What will happen if we do not follow that path? To me it is fairly simple: Almost half of employees admit to bypassing security controls.

[…] half of sales-focused employees say their job is hindered because they aren’t getting access to all the information they need. And with more than half of the respondents working for large organizations (the majority employing more than 5,000 people), the potential ramifications are notable.

A lot of security people I know have a false sense of security. Do you think that internal security knows of these bypasses? No, not at all:

That’s breeding apathy, too: 40% admitted that if they were breached no one would notice.

If we do not help our users to do their job in a secure and safe way, we risk our business. Think about it again:

While 40% of companies have lost a sales opportunity because employees weren’t able to access the information they needed, an alarming 46% avoided the possibility of losing a sales opportunity by bypassing security controls to access necessary sensitive information to get the job done.

Can you really blame your sales? Kind of but they are measured by making money. What would you do in their shoes?

How much does this have to do with the BYOD? Well a lot to me as it is just the next big wave – actually the one we are riding since smartphones came up. Our users need access to information wherever they are the way they need it. Our job is to protect the company’s assets in this context.

The way we at Microsoft do it, is that we apply something we call “Variable User Experience”. It bases on different factors:

• Identity: How did the user authenticate? With a consumer identity like LiveID, Facebook or with Active Directory. For certain access the Microsoft Account (former LiveID) might be good enough. Did he/she authenticate with UserID/Pwd or with two factors (we use virtual Smartcards in Windows 8 today, so my computer acts as second factor and I do strong authentication).
• Device: Who manages it? Is it IT Managed, Employee Managed (but still in AD), or unmanaged? Is it authenticated? Is it in a policy compliant state?
• Location: Is the device on the network or outside on Direct Access/VPN? In which country is the device?
• Data/Application: What kind of data is being accessed? Which sensitivity level?

Based on these factors, I might have different routes to what I need to do:

• Direct Access/VPN: I might be able to access the network and all the data through DA/VPN requiring Strong Authentication
• VDI/Citrix: If not, for any reason, the fallback is a Terminal Server session, where I do not have any local data but might still require strong authentication.
• Web SSL: Web based apps, requiring simple authentication. Maybe even through Office365, which I personally use very often.
• Denied.

I do not say that we should loosen up everything so that every user can access highly sensitive data on the unpatched and unencrypted iPad or Windows XP. There is a “Denied” in there and it has to. There are administrative (HR) processes in there for violation of policies and it has to. But we have to give the user different – SIMPLE – ways to achieve the goals they have to or they will spend a lot of energy to find ways around our security controls.

I know that we as security people can sleep well when we have all the controls in place. We did everything to secure the data and if it fails, the user is to blame and not us. But this does not help the business we are supporting, does it?

If a CEO or CIO reads this and nods now (which happens to me often, when I talk about this subject) – you have a role in there as well: If the “shit hits the fan” and a security incident happens, think twice before you fire the Security Officer. We talk about managing risks. Risks have the tendency to materialize once in a while – and basically you should fire the CSO only if he did not do his homework or if he does not have a proper incident process. Otherwise you create a culture of “CYA” (Cover Your Ass) and not the openness and trust you need to land such a strategy.

I guess a lot of people disagree now J – let me know!

Roger

Related articles

• Giving employees a say over business technology (windowssecrets.com)
• 4 Mobile Security Predictions to Help CIOs Plan for the Future (networkworld.com)
• Employees Fret Over BYOD-Related Privacy Issues (misco.co.uk)
• 72% of enterprises see BYOD featuring prominently in the near future (misco.co.uk)

Roger

About 12 months from today, Windows XP will go out of support and the discussion with some customers reminds me of the Conficker situation. Everybody knows, that something bad can happen and most probably will happen but we close our eyes. One of the reasons in this case is, that Windows XP just works and the migration is expensive.

As of end of April, we currently see about 30% of the devices used in companies still running Windows XP – running an Operating System which was designed and developed when we still used ISDN, Wireless LAN did not really catch broad attention and I worked with Token Ring during business hours. And 30% of our customers trust this operating system to protect their business? Not only from a confidentiality point of view but what about availability when a broader attack happens? If you need a slide deck, which shows this evolution, I posted 2 slides, which land extremely well in Windows Security Evolution.

To me, this is fairly close to not rolling out security updates. I wrote it more than once: Keeping your software on the latest version (not only ours but third-party like Java, Adobe, Apple etc as well) is probably my number 1 ask to customers to keep their environment safe.

If you need help for the migration, there is a lot of good content out there – but please start, if you have not already done so:

• Windows XP to Windows 7 Migration Guide
• Windows Assessment and Deployment Kit (ADK) for Windows® 8
• Microsoft Application Compatibility Toolkit 5.6
• Microsoft Assessment and Planning (MAP) Toolkit for Windows 8, Windows 7 and Internet Explorer 9
• Microsoft Deployment Toolkit (MDT)
• The Windows Automated Installation Kit (AIK) for Windows 7
• User State Migration Tool (USMT) 4.0 User’s Guide
• Windows XP to Windows 7 Hard-Link Migration of User Files and Settings
• Windows 7 Upgrade Advisor
• Windows Optimized Desktop Scenarios – Solution Accelerator

Help me, to sleep better – when the figure of the 30% Windows XP gets much, much lower

Roger

Related articles

• Decline of Windows XP usage stalls a year before its 2014 death (digitaltrends.com)
• Did Windows XP or Windows 7 Come First? (smallbusiness.chron.com)

Roger

Related articles

• Worldwide Map of Internet Connected SCADA Systems (cyberarms.wordpress.com)
• The SCADA security challenge (net-security.org)
• SCADA’s frighteningly exposed underbelly (blogs.techworld.com)
• Thousands of Finnish SCADA systems vulnerable to attack (asherwolf.net)

I just saw a new approach to the same problem, which I personally pretty much like. It is solving a very difficult puzzle (like put the right toppings on a pizza) – something you should look at: http://areyouahuman.com/demo/

Roger

Related articles

• 18 Extremely Strange (Yet Real) CAPTCHA Messages (techeblog.com)
• Ticketmaster Ditches Annoying CAPTCHA Verification Process (wcbsfm.cbslocal.com)

1. Centralized logging makes it possible to review all the logs
2. SIEM is French for “locked down”
3. Event correlation helps you find bad things
4. Search and destroy
5. Compliance, covered

I would like to add a few thoughts to this and add some of my reality.

We all agree (and often tell our customers), that monitoring is probably one of the key ways to find targeted attacks. Obviously, monitoring does not prevent the attack from happening but you can find it much earlier. This is true.

My reality shows, however, that most networks are not in a state from a hygiene perspective that the noise they generate is on an acceptable level. Often customer buy IPS, IDS just to realize that the number of alerts they get in one day keeps them busy for the rest of the week – only to figure out, which alerts they need to look at, not to say to really act on the suspicious one (I know that this is exaggerated but it comes close to the truth). To me, the problem with event logs today is two-fold:

1. Even with a reasonable setup, the amount of data generated is huge. As an example: A customer once tried hard to focus on the key events only. So, they e.g. switched off a successful logon event for their users. While this, initially, might sound like a smart idea to reduce the load, it led them to a difficult situation: one day, somebody was trying to guess a password of a user, so the admin saw an unsuccessful logon attempt, an unsuccessful logon attempt, an unsuccessful logon attempt, an unsuccessful logon attempt, and so on and then it stopped. Does this now mean that the attacker gave up or that the attacker finally got the credentials? While this is a fairly simple and not too sophisticated example, it shows the problem. You need to collect a lot of data and then search for the needle in the haystack. And this is a lot of work for very experienced people and the tools in this space to my knowledge are not too sophisticated.
2. Event correlation sounds good but is very complex. I agree that event correlation could show a lot of possible attacks – if we know what we need to look for and correlate. That’s the key problem. To correlate events in a meaningful way, you need to understand all the details behind the events of each and every application and then try to understand how an attack looks like. Even though there are tools here, the work to make it happen is significant and I am unsure of the return.

Again, it is not me saying that the proposal above does not make sense. It does but we should not oversimplify the complexity of such an effort and the return we expect. To me, we need to make sure that we understand the network and the data, and that we can do a proper threat modelling on there and understand the security boundaries. Segment the network is still one of the key prevention techniques (besides keeping all your software on the latest version). Once we are there, we can understand what we need to monitor and where. Otherwise, such a project is subject to failure (or a very high cost) in my opinion.

Roger

Related articles

• Playing chess with APTs (blogs.gartner.com)