The first course that I attended at engineering school was on engineering ethics. Ten whole hours on this topic, with a retired nuclear engineer.
As a 20 year old, I did not fully grasp the importance of the topic, and frankly I did not pay much attention to what was being said. One idea stuck though: we, engineers, have an ethical responsibility towards our users, coworkers, organisations and society at large.
All engineers are concerned, but today, we’ll focus on some ethical considerations that security teams often face.
Bug bounty temptation
The first one is obvious.
Bug bounty programs can create interesting situations if the employees who run the program decide they want to join in on the fun. First off, insiders can leverage their position within the company to find bugs more easily. They can then submit these findings as external bug bounty hunters, and approve the reports, effectively paying themselves.
The bad kind of security monitoring
Security monitoring platforms, aka SIEMs, give security teams a lot of information, that other coworkers do not have. Ideally, SIEMs centralise security logs from all tools within the organisation. Usually, that includes identity provider logs, instant messaging logs, email server logs etc. In a similar manner, EDR agents can provide direct access to users’ workstations, and more specifically access to the filesystem.
It becomes trivial for a user with nefarious intentions, to gather insight on coworkers’ physical locations, interactions, and other sensitive files they might have stored on their work machines.
Handling reports gracefully
Security professionals have a decision to make every time they receive a report about a security vulnerability, be it from inside or outside the organisation. They can either accept the report and thank the person who submitted it, or they can respond defensively and treat the reporter as a problem to be dealt with.
When a report is treated as “hostile” by default, it can quickly escalate into reputational damage, unnecessary HR scrutiny, and a chilling effect across the organization. Even the perception that reporting will lead to punishment discourages people from speaking up again. This means fewer vulnerabilities get surfaced early, and psychological safety within the org is harmed.
Handling incidents tactfully
One of the most devastating types of security incidents is insider threats. It happens quite often, and it puts security teams in a bind. On one hand, it’s important to move quickly and decisively, and on the other hand, it’s also important to uphold fairness and due process. Ideally, the people handling the situation keep their emotions at bay and do whatever is necessary. In reality, people and organizations are fallible, and decisions can be influenced by stress, bias, or incomplete information.
The situation becomes even more complex when the “insider” is acting as a whistleblower. What should security folk do then? This raises so many legal & ethical questions, and I’m not qualified to answer any of them.
What can be done?
You can advocate for more separation of concerns, tighter controls, more procedures and increased surveillance of the security team. Realistically, small tech organisations can’t afford to do that. That’s why it’s important, in my opinion, to screen security hires for high moral standards. It’s not easy, or fun, but it helps make everyone’s lives a tad easier, fairer, and more secure.