Archive

Does my cloud have the flu? IT security check-up in the cloud

Share this post:

Abstract

Security health checking is an important IT security process. The question is how can the security requirements of customers be implemented effectively in the cloud environment? How can human interaction with the cloud avoided completely or to a large extend?

Built-in security and health check

When you buy a new car you automatically expect some built-in security in that vehicle, such as seat belts and air bags. Some car vendors might offer additional safety features like collision-prevention systems, which you can additionally order. Similar built-in security feature expectations, such as password or harmful code protections, are there if you buy a desktop PC, a notebook, or a handheld device. Depending on the security needs of the user of those devices, additional security features might be offered by the vendors and activated by the user.

When it comes to the implementation of agreed customer needs in an IT environment, things get complicated. Several thousand individual security settings might be agreed to in a customer policy and the related technical specifications documents for the various devices, OS, middleware and applications being used. Those settings are regularly documented in various office tools and stored in various databases. Privacy and confidentiality considerations may have to be taken into account. All of this leads to more constraints for automation in traditional as well as cloud implementations rather than supporting structures.

Human interaction is often required to find, read, understand, and implement agreed customer security settings with a high potential of errors and failures. The question here isn’t whether security settings are not correct but how many of them are incorrect? Because the process for verifying that the agreed customer security settings are in fact implemented is called health checking, the question becomes how ill is your IT environment?

Potential for automation

What is needed is obviously a systematic approach to address each of the hindrances mentioned above to make health-check automation possible:

  • First, the customer-agreed policies and technical specifications documents must be available in machine readable format. This ensures that each time a security setting is changed, the systems that have implement those setting are aware of this change instantly and automatically.
  • Second, a vendor or service provider set of security settings is needed. Those settings should incorporate best practices information also. With that requirement, all security settings will have an initial value so the system can run as such without explicit customer specification for each value.
  • Third, the system should not allow manual entries or changes in conflict with the policy or the technical specifications, where applicable. A permanent system to check the actual security settings coherence with the agreed values must be established.
  • Finally, the system should allow suppressions of detected deviations to agreed or predefined values. This permits exceptions for some devices to be set without changing the policy or the technical specification documents.

The approach described here can make a higher degree of health-check automation possible. This is applicable for traditional and cloud implementations.

Some security settings or requirements that have to be verified during health checking cannot be automated. One example is the privileged user ID verification: A manager will have to verify the continued business need of a user. Even if the system can help to generate things such as user lists, the verification task has to be completed by a human being. The approach for manual health checking should be to perform those tasks in reasonably long intervals, maybe on a yearly basis, or to accept and document the risk for not performing them at all, where appropriate.

So, when you buy a new car and start to drive it, you have the confidence that necessary security considerations are done and security settings are implemented. You may still want to set a different value in the speed regulator, so the system – your new car – will continue to fulfil its purpose. You still have to decide who else is allowed to drive your car. This decision of yours cannot be automated.

Add Comment
No Comments

Leave a Reply

Your email address will not be published.Required fields are marked *

More Archive Stories

Why we added new map tools to Netcool

I had the opportunity to visit a number of telecommunications clients using IBM Netcool over the last year. We frequently discussed the benefits of have a geographically mapped view of topology. Not just because it was nice “eye candy” in the Network Operations Center (NOC), but because it gives an important geographically-based view of network […]

Continue reading

How to streamline continuous delivery through better auditing

IT managers, does this sound familiar? Just when everything is running smoothly, you encounter the release management process in place for upgrading business applications in the production environment. You get an error notification in one of the workflows running the release management process. It can be especially frustrating when the error is coming from the […]

Continue reading

Want to see the latest from WebSphere Liberty? Join our webcast

We just released the latest release of WebSphere Liberty, 16.0.0.4. It includes many new enhancements to its security, database management and overall performance. Interested in what’s new? Join our webcast on January 11, 2017. Why? Read on. I used to take time to reflect on the year behind me as the calendar year closed out, […]

Continue reading