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.
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?
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.
No comments:
Post a Comment