There was a time when data was able to stay within an
organization – servers were in the company owned data center, users were in
their offices and laptops were a dream, tablets not even conceived. Data security in this setting was easy, it
stayed in the office and the office had physical controls of who could come and
go and passwords on who could login.
Today, users need to work anywhere, this means that data,
often confidential, must be circulated and shared so that these nomadic users
can access it. This introduces lots of risk about data locality, lost devices,
captured data in transit and prying eyes.
A highly nomadic user is one that needs the same access and capabilities,
regardless of location to execute their job duties. Highly nomadic users may
use a variety of devices, some company owned and others personally owned, but
will require the same levels of access. Nomadic users will change behavior
patterns based on projects, deliverables and end-customer requirements.
In the world of cloud-first IT, many organizations have to
change their security posture to more closely align with a nomadic workforce
and the behaviors that go along with it.
Cloud first for many organizations means quickly deploying applications
or migrating applications to public cloud solutions. While this can provide benefits for the
financial aspect of IT operations, security must be considered because of the
changes in application architecture, user profiles and data storage.
We know how to authenticate users and we know how to encrypt
data. What we are still learning and developing is handling the social aspects
of data. Who accesses the data? How is
it combined? These are all solvable
problems with today’s technology, but need to be thought of up front. Security is only as good as the weakest link,
policies for passwords are no use if the passwords become so complex the people
write them down. Encryption is of no use
if key management is not handled in a consistency security and reliable
fashion.
A few scenarios that affect nomadic users:
- Imagine someone is checking an email in a bar, another individual casually peers over the first individuals shoulder and sees a confidential client name and M&A in the title. That is a serious breach of confidentiality. How do you train staff to be vigilant? How do you protect from highly sensitive data being inadvertently seen in public locations?
- Imagine an employee that uses a personal device and has a habit of downloading everything locally. This employee then resigns to work at a competitor and connects their personal device to that competitors network. How do you track what information they had locally? How do you make sure they removed it when they left? How do you ensure it is labeled as confidential? How do you monitor public sites to ensure that information is not leaked?
- Imagine a user that regularly accesses confidential information about M&A activity is working in a coffee shop and has his laptop stolen when he gets up to place an order. What information did he have on that laptop? What deals did he have info about? Encryption and passwords only solve part of the problem.
Security should always be part of initial application design,
even for POCs. There is often not enough
time after a POC to go back and refactor to be secure before going into
production. Many organizations will
forgo security design and feature development as part of rapid prototyping or
POCs. The struggle comes when that initial
code becomes production, even when the initial expectations were to rewrite
things for production, but expediency won out.
Even POCs and prototypes should include a framework and features for
basic security like encryption and authentication, making addition of features simpler
as time goes on.
The solutions are technical, procedural and habit driven. All
three considerations are required to ensure secure environments with nomadic
users.
·
Technical – Every application should
have a plan for how data will be handled end to end, with a risk assessment of
how nomadic users will access the data, use the data and potential points that
data could be compromised. Technical
architectures should then have design guidelines for how data is handled,
encrypted, shared with other systems and audited in a reproducible way.
·
Procedural – Every organization
should ensure that the processes used for development, collaboration and architecture
include checkpoints for security. These
processes do not need to be heavyweight, but do need to have checkpoints to
ensure that security of the data and users are accounted for in design and
testing.
·
Habit – A lot of security posturing
is about the habits of those developing and using specific applications. A culture should be established of
security-first for all IT work and reinforced for all staff. These habits become the key to protecting the
company as change in applications occurs and new features are brought online.
Often times with modern tools the data itself is not nomadic.
The core information being used to generate the report is sitting safely in a
datacenter far away. The nomadic part is
the discussion about it (email) and the results (graphs, reports, presentations).
This nomadic aspect of data presentation, viewing and sharing should be a key
component of all application and big data solution designs. Design considerations should include where
data is stored, how it is viewed, compliance and response to incidents. This up front planning will lower the risk of
compromise, and ensure a solid foundation for later growth of the application
without expensive and complex refactoring.
No comments:
Post a Comment