Flexible Security

I recently read an article which suggested that as our IT systems become more complex, they also become less secure from the sheer amount of code, applications, management systems, and equipment involved. While I agree with the fundamental logic presented by this argument, I believe that as systems have become more complex, we also now have more options to automate and monitor our environments than we have ever had before.  I have personally seen the opposite trend occurring; Though it is true that systems are becoming more complex, new technologies are allowing us to actually simplify our environments and reduce the number of security and monitoring solutions we need to perform our daily tasks.

http://cybersecurity.mit.edu/2013/11/from-thin-air-security-in-complex-systems/

However, I have recently experienced a situation where deploying a new monitoring and security solution actually violated our security policy.  The protocol that the solution used was one of the banned protocols that our security department has deemed to be unsafe.  This situation led to a discussion of mitigation and the vulnerability versus benefit of the new system.  Thankfully, we were able to work with our security department and mitigate most of the vulnerabilities that concerned our security department and then successfully integrate the system into our environment.  This one security and monitoring suite replaced three current systems all using different connections, methods, and protocols, and actually reduced our overall risk exposure.

But what if we had been unlucky enough to have a security department that practices Security Theater? Because the needed protocol was on the banned list, we would have been summarily denied permission to implement the new system.  This would have forced us to leave the existing systems in place and left us in a more vulnerable position.

While in this particular situation the benefit outweighed the risk, each new system needs to be evaluated not only against the stated security policy and requirements, but also against a risk versus benefit assessment. Not every new system will fit the mold, and security requirements need to evolve with changes in technology. However, if a new system clearly does not meet requirements and does not provide a benefit that outweighs the risk, it should be denied.

http://searchsecurity.techtarget.com/How-to-sell-risk-assessment-benefits-to-IT-execs

Security policies and requirements are good guidelines for initial system selection and design, but they need to remain flexible in today’s ever-changing IT environments.  A policy written even a year ago is probably already out of date.  As needs and technologies change, a good security department will adapt and change with them. This type of flexibility will allow a truly secure and functional environment, not just a checkmark in a box.

https://www.cisco.com/en/US/prod/collateral/vpndevc/dynamic_flexible_security_architecture.pdf

Planning for Security and Functionality

If you have even been close to a TV, radio, or internet-connected PC in the last month or so, you have no doubt heard about the problems with the HealthCare.gov website.  I’m not about to debate beliefs or opinions about the new health care law, but I would like to point out the latest issue that all the news sources are talking about now.

http://www.cnbc.com/id/101225308

It seems that there was never any security built into the system; It is even questionable whether security was even a consideration during development.  This surprises me for a couple of reasons.

First, speaking as a contractor to the federal government, one of the first things we are taught is that security rules supreme.  There are several guidelines and requirements that every single system must meet before they will be allowed to touch a production network.  These same systems are then checked again by a certifier to verify that it has actually been secured according to requirements.  As a government-managed project, I would have thought the same protocols would have been followed, especially considering the type of personal information being entered into this site.

Secondly, any developer, systems engineer, or IT professional knows that it is much more difficult to implement security (or any new function) after the fact than to design the system with the added security or functionality in mind.  Most applications have a basic feature set, and for a license fee, you can add additional functions or features.  The base product is usually designed with this capability in mind (or perhaps the additional features are not quite ready for the initial release, but will be added later with an update).

My point to this is that usually there is a balance we seek between security and functionality, but what do we do when there is a lack of both?  Can we add external layers of security to mitigate an inherently insecure system?  Can we augment or expand a poorly performing system that is very secure?

http://emilonsecurity.wordpress.com/2010/10/17/security-functionality-usability-security-trade-off/

Usually we encounter these types of issues with older legacy systems that still provide a needed function but were never developed with the types of security requirements we face today.  A comparable alternate situation might be when systems were originally developed for a very specific function or use case that has since expanded outside of the original intent.

Arguably, the correct answer is to mitigate as much as possible the security or functionality issues you are facing until a newer version or perhaps a different solution can be found to provide the needed functionality, performance, and security requirements you are currently facing and that will also fulfill future security requirements for a predetermined amount of time.

A constant review and reassessment of your environment will let you know where your weaknesses are and how to plan for a resolution.  More importantly, devoting equal attention to both security and functionality planning will prevent future catastrophic roll-outs like the HealthCare.gov website.

Security vs. Functionality

My name is Bill Guthrie; I am a Virtualization Engineer/ Architect specializing in VMWare and Microsoft solutions.  I have over 20 years’ experience in the IT industry working for commercial enterprises, state and local governments, education, health care, and finally the federal government.  I have a BS in MIS and am currently pursuing my Master’s degree with an emphasis on cybersecurity. I also possess several industry level certifications such as MCSE and VCP, and I am currently working on my VCDX from VMware and possibly looking at my CISSP in the near future.

In my line of work, a huge focus is put on information security, and the discussion of security versus functionality happens quite often.  To a certain point, security and functionality have an inverse relationship – The most secure server is one that is off, but of course provides no functionality. Conversely, a fully functional server may well be very unsecure.  The real trick (and goal) is to reach the point of having a server that is secure and still provides the desired or needed functionality.

See “Information Security:  An Exercise in Risk Management” at http://www.eonetwork.org/knowledgebase/specialfeatures/Pages/CommunicatingYourMessage.aspx

There are several deterrents that commonly stand in the way of achieving this goal.  Untrained administrators may not know the proper way to secure a system, blanket policies might not take into account changing technologies, or activities may end up as paperwork security or “security theater” (where the perceived security is mostly checking the boxes for a stated standard but not really understanding the underlying rationale).

Many organizations seem to put random or counter-intuitive security requirements into place, such as requiring 16 character alphanumeric passwords with special symbols, when there have been several studies that show that passwords over 8 characters actually reduce security as users and admins will write them down and keep them close to their work areas.

Security is an absolute necessity and should be one of the first considerations of any organization; however a balanced and smart approach will prove to be much more beneficial and will provide a much better security posture.  As both public and private industry increase their information systems and applications, a trade-off between functionality and security must be achieved.