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.