Tuesday, September 4, 2007

Got Security?

After a couple of good days in Boulder, I am now down in Sydney – and what a change! Not just in terms of the weather, as Sydney is coming out of Winter and the first days of Spring are pushing up the thermometer whereas Boulder continue to bake in some of the hottest weather it’s experienced all year.

The real shock has come in arriving in "Fortress Sydney"!

For the week we are here there is the APEC conference – a meeting involving the heads of state of the US, Russia, China, Japan and many other countries that ring the Pacific. Concerned over the potential of demonstrations and even terrorist actions, the CBD has been surrounded in concrete and 10 foot high fences.

I have included a picture (above) here to give you a feeling for what it’s like – the perimeter goes for miles as it fences in most of the North Eastern corner of the city including the Opera House, the residence of the Governor, and most of the major hotels.

Gates have been set up to control access into the restricted zone. Police are highly visible checking all credential and there are helicopters in the air at all times. We have even heard an F18 fighter plane make a couple of passes over the city. The Navy and Water Police are also highly visible

I have never seen anything like it and until I paid the city a visit to take a look, I hadn’t thought it was possible to lock down a city the size of Sydney – but they seem to have pulled it off. They have sealed it all off and limited access to a select few entrances through highly controlled gateways.

And this really made me think about the security and what we are doing today to secure our systems. Back in the 70s Honeywell went so far as to provide a system with no comms or networking capabilities whatsoever, and went on to promote it as completely secure! But I don’t think that will be of any use these days in the highly connected business world we all have to deal with. Essentially, we have to live with systems that have many entrance gates and with access allowed from pretty much anywhere in the world.

Corporations that I talk to, often change gears on me, and talk about meeting regulatory guidelines and requirements. But is compliance really what security is all about? And is it only an issue for larger corporations? Does security really involve every organization we deal with in our technology ecosystem – from the large vendors all the way down to the smaller specialist tools and monitoring companies we deal with day to day? In erecting our own fences and opening only a few gates, do we really believe we can secure all the applications and data bases we are responsible for?

So, is compliance a well defined path toward security? Is it because we don’t know what would make systems secure that we happily comply thinking it relieves us from the responsibility of defining security ourselves?

Or, we comply grudgingly, knowing well enough that following the rules defined by regulations doesn’t change a thing?

I have to admit, seeing the steps Sydney has gone to in order to demonstrate how seriously it was taking security, only reinforced in my mind how open to all sorts of threats we really are. There has always been the saying “I don’t really know what I want – but I will recognize it when I see it”. Today I have just seen a city locked down and secured – and I am pretty sure that’s what I would want if it was my responsibility. But have any of us really seen a system so secured that they immediately recognize that it is exactly what they need for themselves? I am not sure I have seen such a system yet!

Reading your entry got me thinking further about the similarities between the decisions made to secure APEC, and the decisions we make to secure our information systems.

With APEC, a decision is made to find a meeting location that meets the needs of the conference. Details such as hotel capacity, seating capacity at conference venues, general presentation facilities, catering facilities, and of course, the ability to secure the area are all taken into account when determining where the meetings will take place.When determining an information system to use, we follow a similar process. We look at a large number of requirements, including where we're going to physically place the computer systems, what our general business requirements are, and how we're going to secure the systems.

With APEC, certain areas within Sydney were chosen as they met the above criteria. Security primarily consisted of a number of different "authorization points" at which attendees were required to present "credentials" for "authentication". The 10ft high fence around areas of Sydney with limited entry points was the first of these layers. After having provided their credentials for a cursory examination to pass through this first authorization point, attendees were then required to provide their credentials to a second authorization point that did a much deeper verification of their credentials, for example, confirming not only that the credentials weren't forged, but that they hadn't been revoked. These are the two layers that I was aware of, and it wouldn't surprise me if there were other layers as well.When we create our mission critical information systems, we take a similar approach... we choose a secure location to setup our data center, we select a platform and operating system and applications that meet our needs. We then secure them at many "authorization points" providing a layered security infrastructure. We physically secure the information systems, we secure them at the operating system layer, we secure them at the network layer, and we secure them at the application layer. This security is provided by a series of authorization points that require some form of authentication based on one or more credentials.

Regulatory compliance such as the PCI data security and PABP standards provides guidelines for security at each of these layers, and although being PCI compliant doesn't necessarily mean that you are secure, it serves a number of useful purposes, e.g. provides a good starting point/reference for managing and auditing security within your enterprise, it raises the importance of security to upper management and helps in obtaining funding, and it also helps to focus the industry vendors on working together to provide secure foundations in which to meet these security standards.So, in answer to your question of "Is compliance a well defined path to security?", I'd be inclined to answer yes, assuming that enterprises view it as guidelines to use to improve the security of their systems, and not as a regulatory burden that just "has to be met".

Just as certain areas of Sydney are good for security, I believe that the NonStop is also good for security. Having been party to a few PCI type audits, auditors pretty much consider running on the NonStop to almost be a "compensating control" of it's own, due to it's well designed security, and relative obscurity in the industry. However, other platforms and operating systems are catching up, and may have even surpassed the NonStop from a security perspective. For example, windows and UNIX based systems have multiple options for file level and database level encryption of data at rest, what are the plans to provide this for the NonStop?Almost all other operating systems provide IPsec support, what are the plans on the NonStop for this?Although I'm not advocating one personality over another, I wonder if the move towards OSS, and an open systems environment, could remove some of the security advantages that the Guardian personality has provided the NonStop platform in security? Perhaps the "security through obscurity" provided by the Guardian OS has run it's course (like most other forms of security through obscurity), but I'd be interested in peoples thoughts on this?

Are people working on other security guidelines/standards other than PCI? Are our NonStop sysadmins invited to take part in the overall planning of the layered security approach within their enterprise?

Anonymous (NJB) - you raise a couple of good questions here and I have passed them on to Product Management (and copied the Security SIG moderator) and will be checking back in with them for a response. Let's see what happens here.

Richard was kind enough to let me know about the security discussion on this blog so I could post a comment. Just to let people know, I’ve been recently assigned as the Product Manager for Security for the NonStop server. I’m part of a team working with Wendy Bartlett on the technical side to create a well rounded roadmap for future new product offerings to improve security options on the NonStop server. I completely agree that “security through obscurity” isn’t enough anymore. While the NonStop OS gives customers some security advantages, the platform needs to integrate with the rest of the computing world and we’re working to make security on the platform one of its key advantages alongside performance, reliability and scalability.

The team here is examining all options to provide security improvements, from deals with partners, to leveraging initiatives inside greater HP, to enhancing existing products, to incorporating security as a natural part of new products in development.

An example of a recent security product offering is the HP NonStop SSH product, which was announced last month for the NonStop Integrity line and will be available for S-series platforms soon. If anyone wants to know more about what we’re up to, joining the ITUG Security SIG is a good way to find out. Also please feel free to email me at: Karen.Copeland@hp.com.

Hi everyone,I’m the security technical lead for the NonStop server. I’d like to add a response to the questions about the OSS environment. While OSS is POSIX compliant, OSS is not POSIX, UNIX, or LINUX. OSS does use the high-level interface code from the OSF/1 implementation (http://www.osf.org). However, the low-level kernel code was implemented by HP on HP’s NonStop Operating System to our own software engineering standards and therefore inherits the NonStop Operating System fundamentals.

As is the case with Guardian, non-privileged (user) processes running under OSS cannot corrupt the code space of another process running on the NonStop Server, corrupt the data space of another process running on the processor unless the two processes agree in advance to share memory (and even then only the shared memory could be compromised), or escalate their set of privileges.Best regards,Wendy Bartlettwendy.bartlett@hp.com