How to talk about the possibility of the admin being an insider threat without offending?

Question

I work on the Information Security team and my job is to look at various applications used by a multinational finance company to analyze the design of the systems find potential security risks - mainly around insider threat. This is very different than trying to fix a problem that has already happened.

In most cases, the admin of the application will have full authorization and can cause millions of dollars of damage. The catch here is that in order to understand the application, I usually work with the current admin(s) (just two admins in many cases). I'm afraid I'll be met with hostility when I suggest that the person I'm working with might be an insider threat. After all, I'm making a career out of doubting hard working, loyal employees.

I'm fairly junior regarding my title and my tenure with the company. So far, I've mainly dealt with others who understand how Information Security works. Now, it is getting to a point where I will be working with application teams of all levels all the way from VP/Architects to a junior admin. How do I navigate the conversation around security without making it seem like I'm pointing fingers, when I'm really not?

I pre-face the conversation with certain scenarios where it seems like they are not responsible:

1. If a new person were to join your team, they might make a mistake and cause damage
2. If a disgruntled employee knew the password to the account
3. If you were on PTO and your task has been delegated to someone less familiar with the system

Sometimes they work, sometimes I still run into hostility. What can I do to make sure that they understand that this isn't personal?

Answer 1

I would fall back to how engineering designs are analysed and reported: the Failure Modes Effects Analysis.

The FMEA was developed to help improve the reliability of new designs of US military equipment. The standard form is designed around manufacturing, but part of the Analysis is potential failure in the manufacturing process including human error or sabotage. And it idea behind it is to identify the potential problems and try to detect those problems as early as possible. Which is really the same thing you are doing here. Just on an virtual system not a build product.

I would probably modify the standard form to make it a bit simpler to use.

• List out any and all potential problems in scope for your role. (failures)
• For each failure make a list of ways that the failure can occur (Causes)
• For each Failure make a list of potential Effects that could result.
• For each Cause rate how likely the Failure is be detected immediately, in 1 day, 7 days, 30 days
• For each Effect rate how bad the effect is to the organization
• For each combination of Cause and Effect rate the effort require to fix based on when it is detected (immediately, in 1 day, 7 days, 30 days)
• For each combination of Cause and Effect rate how often you would expect it to occur - This is not about a specific person. Just an in general how often a generic business can expect the failure to happen.

For your ratings use a 1 to 10 scale. There are no zero's because if any of them were 0 then they do not belong in the chart in the first place.

Scale for Occurrence:

1 - not likely to ever happen
3 - Once a decade
5 - Once a year
7 - Once a Month
10 - Going to happen in normal conditions

Scale For Effect

1 - Not fixing it will have minimal impact, or can be fixed easily
3 - Can work around it, no rework required
5 - Can not work around it, or rework required
7 - Can not work around it, and rework required
10 - Impossible to fix, or fixing would be prohibitively time consuming or expensive

For detection I would just do a 1 = 100% and 10 = 0% with 10% increments

You can of course use your own scales these are ones that my group came up with when we designed some mission critical applications for a fortune 50 company.

Answer 2

As a fellow information security professional with similar duties working as an IT auditor, I feel your pain. :) Our work is not "popular" in a company for a reason, due to our responsibility to protect assets, and monitor security compliance. Great job for recognizing the risk, albeit how unlikely, that any insider can have malicious intent and are a potential threat to security.

You absolutely cannot back down when confronted if you are to remain effective in doing your job. Security risks are not something management or senior employees is ordinarily willing to talk about. So first learn to accept a certain amount of conflict is inherent in the nature of your job.

Having said that, the preliminary list given by @dlb is a good start. From that list, you can derive some inherent risks inherent to privileged Admin role. Its pretty easy to list some and how he can hide his actions:

The risk to Confidentiality of data leakage

The insider Admin copies some sensitive financial data and electronically sends it out of the company to himself or a competitor. Competitive intelligence is lost, and the economic value of the lost data can be significant, maybe even business survival relevant.

The risk to Integrity of unauthorized data deletion

The Admin decides to erase some data used in the database or otherwise tamper with stored data. Now data integrity has been compromised and the resulting potentially false financial reporting can lead to huge regulatory fines.

The risk to Availability through various methods of DOS / DDOS

Applications used by financial companies are often time sensitive, fr example to capture accounting transactions, or to process extremely time sensitive asset trades on the market. A attack that result in loss of ability of legitimate users and / customers to access the application is a loss because of opportunity cost of the extra time required to process the original work.

Example of how the insider admin can hide his actions

• Erase or tamper with audit logs recording his activity
• Disable or tamper with any application alerting functionality that may be in place

Making management aware of the difference between inherent risk, the security risks present before any safeguards are implemented and residual risk, the security risk that remains after safeguards (technical, administrative, and / or physical) is implemented is my first suggestion to you. Use specific, concrete examples of inherent risks and the associated impact, similar to examples given here.

Without security safeguards in place, any of the risks identified in the preceding paragraph can easily impact this financial system resulting in loss to the company. This bring me to my second suggestion - educate management and other non security savvy folks, how safeguards such as DLP can be used to mitigate security risks. As an example:

Through DLP implementation we reduce our risk of sensitive data exfiltration.

When explaining or suggesting new security controls to be implemented, cite your research to show why implementing this particular control / process will improve cybersecurity - think CIA here. Refer to best practices using sources such as NIST, SANS etc. This shows that your recommendations are not arbitrary but based on solid reasoning. Also, it is important to stress you and your team are not there to make anyone's job harder, but to partner with them in improving operational security. Show how having good security practices will benefit the company - improved customer confidence, less downtime etc.

Finally, IT security is about risk and the acceptance or mitigation of such risk. It may be that your management has a large security risk appetite, and is willing to accept security risks surrounding this application. Alternatively, the control environment / tone at the top at the company, may be lax. I.e: management may be pushing back because they simply don't care. Think of the control environment (or the lack thereof) at companies such as Enron, WorldCom, Tyco..

In either of the above cases, you may have to accept your ability to initiate change is limited by company culture and operating philosophy. If management of the company is comfortable in not taking action to remediate the vulnerabilities you find, you should document your communication to them to evidence that you did you due diligence. Nevertheless what management of your company chooses to do, as IT security professionals, we have done our job. Sometimes, giving a warning is all you can do/

If you really want to show your management the potential costs of not remediating a security vulnerability discovered by you, you may have to show them what may happen when such vulnerabilities are exploited by threat agents such as disgruntled insiders , competitors, etc. Examples such this one or these ones should be pretty illustrative.

Answer 3

Is there a way you can work up a generic type list of potential risks and descriptions such as:

1. Inadvertent damage or access - the ability of unauthorized access to sensitive information or systems through automated processes.
2. Uncontrolled or inadequate password controls - allowing too simplistic passwords, not requiring frequent changes or allowing shared passwords creates security risk for reasons X, Y, and Z.
3. Delegation of temporary rights - Persons should normally have access rights at a minimal level needed for their nominal tasks. Additional rights should be granted by first logging in as themselves, then elevating through authorization. Too high of rights for a task are a risk because of a list of examples... and elevation for a task helps track who is accessing and why.

These would be generic rules, written for general grading, not in response to specific issues, more the list of what you are evaluating for. Impersonal and available before you look into a situation, but also a living list that you add to as needed and would have potentially many more points.

Your three scenarios you preface with fit nicely into the three points I made for them. Then, when you see something that concerns you, you already have a pre-defined category it fits is without it seeming like an immediate accusation. If however, the same person or group is behind many entries in many categories it becomes obvious even without accusing or being confrontational that they are an issue needing either much closer look or training.

How well this would work depends on structure and willingness of people to work on it. Tact is definitely a tool that may not always work and no identities attached until needed in the reports may help keep it institutional rather than personal, at least until person correction needs to be addressed.

Just ideas from how I have seen it approached. May or may not help in your situation.

Answer 4

You are talking about "the possibility of the admin being an insider threat". You are picking just the wrong words here. What you are saying here is that some admins are insider threats and others are not, and your admin might be one of the good ones or one of the crooks.

Instead say that every admin is an inside threat. It comes automatically with the position. That way, you are not doubting the honesty, loyalty and competence of the person holding the position, you just state something that the admin knows anyway.

Then let the admin tell you what problems or damage the person in the admin position could cause. Which of that could be avoided and which can't. Let him or her feel important because the trust that has to be put into them. And I think there is a general tendency of people to fulfil others' expectations. If the company trusts its admins, they are more likely to be trustworthy.

Answer 5

Identifying a potential threat doesn't mean "I think Bob may be nefarious," it's saying "if you should ever get someone nefarious in a position like this, where they have complete and sole control, you're going to know pain." - so identifying such an area isn't a slight against the people there. It's just a "heads up" to have other means of monitoring or verifying besides the insider who can do the damage. This is a pretty normal consideration in your line of work, I'd think, and identifying internal weaknesses is very much part of what they are expecting from you.

I don't think anyone will take offense, as long as you are talking about it from a functional standpoint, and not naming individual names, so to speak.

Answer 6

1) Make sure your department sanctions and issues training sessions to the required staff members that go over information security best practices, and what your company expects at the level of their own policies. Also be explicit that the policies are enforced. Just because employees know best practices and have never had an incident, doesn't mean they simply don't do the wrong thing sometimes. Offer a mandatory annual refresher for those who've had the full session once.

2) Don't tiptoe around potential faults. The sad reality is in big, multinational corporations where everything is "professional," some of the nastiest confrontations will come out of you trying to do your job. Financial compliance comes to mind: Everyone has to do it, but if you get on an advisor's case about not doing it, you end up on the crappy end of the phone call. It's not about pointing fingers, it's about avoiding federal fines, lawsuits, and job-ending losses. To-date, I have not found a way to instill this understanding.

The other issue I find is the more terse in your correspondence, the more likely others are to take it as an attack. An example conversation: "Stop doing that, because it will cause X and Y will happen, Thank you," or "Please file your X, it is past due," etc. I find that more often than not this leads to accusations against you that you're being accusational. You can try to pad your talks with hedges, but I'll probably never understand why you'd have to do this in the first place. My suspicion is that people who are more prone to perceiving slights or accusations will do so regardless of intention.

Answer 7

Just commenting to mention this sort of threat is well understood by the Information Security field. In fact here is a PDF from SANS Institute that outlines the various controls which can be applied to prevent damage from the insider threat. In addition, the PDF also mentions methods that might be utilized in an effort to bypass these controls.

Please note I am choosing not to directly answer the OP's question of "How to talk to an admin about the possibility of being an insider threat" as that conversation is more beneficial to take place with a C-Level executive who can put in place the various required controls. Don't agree with it? Thank you for your service at "Company Name" your final paycheck is in the mail.

The PDF Link - Employee Management Security Controls