Information security (IS) and/or cybersecurity (cyber) are more than just technical terms. They’re the processes, practices and policy that involve people, services, hardware, and data. In particular, IS covers how people approach situations and whether they are considering the “what if’s” of malicious actors, accidental misuse, etc.
I’m not sure about your operations teams, but no one in any of mine, myself included, were able to read minds. Therefore, in order to maintain the secure practices built into our policies and procedures, people from other teams needed to be able to read and understand the why of these practices.
We needed to recognize how to be more secure and what actions were considered to be of higher risk within our daily interactions with data, systems, and people. Whilst it was the operations team’s role to train these consumers, it was ultimately the responsibility of every single employee to practice those secure actions.
Within your organisation, you may have read security awareness documentation, attended some training, or even participated in simulations. These are all part of building an understanding of security. Consider it as training for your role just like any other schooling, certifications, lectures, etc. that you may have taken to get the job you’re in.
When you’re unsure about an action to take or process to follow for your everyday job, consider this the same thing. Contact your line manager and ask for resources, training, and support. When reviewing your documentation and procedures, check whether they have security in mind and whether have they been reviewed by IS/cyber operations.
Your role as a member of the IS/cyber defense team is to recognize that the daily interactions you have across the organization—be it human to human, human to system, or system to system—are a part of this role. How can you make these actions resilient to malicious actors, errors, and failure?
Two examples of breaches that could have been minimized or even mitigated due by a robust IS/cyber defense team follow below.
Target (2013)
A malicious actor gained unauthorized access through a third-party provider’s credentials. That is, they phished the HVAC provider and used the credentials to log in to Target. Unfortunately for Target at the time, all accounts on their system maintained access to absolutely everything.
This meant that the malicious actor was able to use this access to collect payment information of consumers. When unusual alerts were found and escalated to the appropriate persons, no one took action to investigate further.
Here are a few considerations that could have minimized and potentially mitigated this compromise: (Further details are available here.)
- Third-party contract review to require continuous AV monitoring to recognize malware that was used in a phish. (The vendor had a free version that ran scans only when they were initiated by the user.) Could compliance, if they knew the value of this, have flagged a lack of clarity within the contracts?
- Following the Principle of Least Privilege (PoLP) for accounts i.e. only granting access that is strictly required to complete the job and no more. Could a regular user who has more access than needed raise a concern?
- Robust internal segregation i.e. HVAC systems and payment systems being separated. Could a network or data flow team member who isn’t security-focused have mentioned this during architecting?
- Simulations and continuous validation of processes. (When an incident occurs, processes are followed and investigated in a timely manner.)
BUPA Global 2017
In the case of BUPA Global, an insider stole approximately 108,000 account details of customers who had a specific type of insurance.
Considerations that could have minimized this incident include the following:
- PoLP: Whilst I do not have inside knowledge of this environment, from what I have read, it appears at the time that PoLP was not followed. An employer should have technical controls in place that reduce unnecessary employee access to consumer information. (Mind you, there are situations where this risk cannot be fully removed. This could have been the case.)
- Data Loss Prevention (DLP): There should be additional controls in place that limit access to consumer information. The organization did have a few things in place, as it was able to determine that there was no loss of medical information. It also discovered the incident in the first place. Potentially, it could have gained even more awareness from technical alerts.
As a non-IS or cyber team member, what are some examples of things you can do to be a valuable part of this defense team and truly embed security by design and by default within your team?
- Important Documents: Does your department use one document, such as an Excel spreadsheet, that they simply cannot live without? How has your team confirmed that no matter what—computer or software failure, accidental deletion of data, persons on holiday, leave —you still can access this asset and it’s up to date? If not, talk to operations about backups, centralized storage, version control and limiting access. Without knowing the importance of the document, IS may not have a solution should something go wrong.
- Secure Authentication: When you log into accounts, is it with a single sign-on (i.e. same login as when you access your computer and email), or do you need to create a unique password and memorize that? If they are not aware of this separate account, IS might not remove/verify removed access when someone leaves or have a suitable solution if a password is lost.
- Joiners / Movers / Leavers: In almost all my security assessments, I at least mentioned JML processes such as how someone is brought on and how their permissions are given. If it’s ‘copy this person to create the account,’ that’s not the right way!
- Joiners: Consider when you started. How did it feel? Organized or confusing? One task you can pick up is documenting what access they forgot to give you and what access you didn’t need. This will benefit IS and ultimately your team because it will reduce the time between when access is requested and when it’s provided.
- Movers: Have you moved roles, or do you know someone who has or is planning to do so? Have a chat with IS. What access will you no longer need, and what different or further access is required?
- Leavers: When someone leaves, clearly they do not need to retain access. Consider the question asked above. Do you have unique credentials that operations aren’t aware of? Let them know.
- Limited Access: Commonly referred to as the ‘principle of least privilege,’ this is all the access you require to complete your job but nothing more. I can usually tell a junior tech from a senior tech based on the level of access they feel they need. Juniors think the highest level of access is exciting, whereas seniors realize that means they hold the highest level of responsibility and request the least possible. This also can protect us when making a mistake. When asking for access level, be mindful of what you need, but realize that any limitation is actually beneficial to you. Only ask for what you need.
- Shadow IT: If you have ever heard of this term before, you might feel the blame is being put on you/the users. The reality is that shadow IT is an issue with communication between users, workflows, and IS. Clear and open discussions on the needs of your team can make for a more secure environment that works for you, not against. Effective change management policies will remove the need for circumvention.
Whilst seemingly small, these helpful hints can improve your organization’s processes. You’re in the perfect position to make that difference. Support with your IS team can go a long way, and improving these procedures can make your workflows smoother.
Notice a gap in security but feel unsure if it’s mitigated through internal controls? Take an IS team member out for coffee and have a chat about it.
I have worked in this industry for over 10 years now. Not once have I gone for coffee to discuss cyber findings and not enjoyed it. Never have I been embarrassed by users asking for advice or requesting further details on processes.
The fact that they’re showing interest and wanting to be a part of the solution means my job is making a difference. Awareness training, transparent processes and collaboration is how we make our environments more secure.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
Mastering Security Configuration Management
Master Security Configuration Management with Tripwire's guide on best practices. This resource explores SCM's role in modern cybersecurity, reducing the attack surface, and achieving compliance with regulations. Gain practical insights for using SCM effectively in various environments.