One of my team members executed security test without any consent

Question

One of my team members, when deployed at a customer's site, executed a password attack against the customer's database. As a result, this customer's database was locked down for 30 minutes.

Now senior management has to make an official apology to our customer. How do I prevent this kind of behavior from happening again?

Answer 1

As Yu Zhang has said NEVER perform security tests without consent. There are no exceptions to this rule.

You need to make it clear to the team member that senior management would be justified in firing him for his reckless actions. For that matter, your customer could choose to take legal action against him including criminal charges.

That said, there are clearly training issues if one of your team members thought it appropriate to run a security test against a customer's live data.

Some things I'd consider in addition to Yu Zhang's excellent points:

• Wherever possible, potentially destructive security tests should be run in an isolated non-production environment. That includes separate servers.
• If a separate environment is not available, potentially destructive or disruptive security tests must be run off-hours when there are few or no customers using the application. In this case extreme care must be taken to ensure no real data is harmed.
• Always have a prior agreement with rules of engagement and stick to it. This must be in the form of a written contract. Emphasize that any security testing without a prior agreement is illegal hacking.
• Don't be afraid to use this incident to remind your team members of potential consequences. Security is important, but one of the reasons all reputable security testing organizations work with detailed contracts and rules of engagement is that security testing in progress is indistinguishable from hacking attempts. I can't stress that enough. To a customer or system admin who has not been notified of security testing, there is no difference between a hacking attempt and a security test in progress.

I was recently involved with penetration testing for one of the applications I test. The penetration testing firm made these arrangements:

• We provided a sandboxed environment that was isolated from and a mirror of our production environment.
• The security testers notified us each day before beginning testing.
• At the end of each testing session, the security testers sent us a brief summary of their findings.
• Every critical vulnerability they found was reported to us immediately
• Rules of engagement included that if they gained direct access to either the servers or the database it was "game over" and they ceased testing and notified us of what they had done and how to fix the problem (this didn't happen, but it was worth having that limitation in place).

It's worth making a list of terms like these for your team members to memorize as standard practice for working with customers.

Answer 2

Security tests should be only executed with a written customer's consent.

• Your team member's intention might not have been malicious but due to its highly sensitive nature of software security, all security related testings must be executed after acquiring a customer's written consent.
• In some countries, owning security testing tools is not legal. The only exception is when these security testing tools are used with consent, otherwise legal actions may follow.
• You should talk to your senior management about educating all employees about getting written consent from the customer before executing any kind of security test. This should be mentioned when an employment contract is signed and should also be sent to all employees as a reminder on regular intervals.

Answer 3

The fact that this thing happened means that there is something wrong in the security testing processes inside your team. At least, there should have been an agreement/consent between both parties - a team that does the testing and customer itself.

Some of the practical things you can do to prevent this from happening again:

• improve education and awareness
• establish formal guidelines/checklists which should include getting consents from all the involved parties (checklists are powerful!)
• set up notifications when security/penetration testing starts
• see if you can improve the existing Security testing tools by having additional prompts explicitly stating which target are the "attacks" are gonna be executed against

• think of something like a "Pink Sombrero" principle - make these actions "loud" and noticeable:

  

  Anyone editing code on a production server is required to wear this pink sombrero for the duration of the work.

Answer 4

how do I prevent this kind of behavior from happening again?

I will assume that this individual didn't know any better.

Someone (perhaps you) needs to clearly teach everyone what is permitted and what is not.

Things like security testing on a customer's system without permission seems obvious, but apparently education is needed.

I'm sure there are many other questionable practices that could be clarified (How is formal permission conveyed? Should testing ever be done in production? Should test data ever be used in production? etc, etc.)

If the individual actually did know better but went ahead anyway, then perhaps he needs to be let go as an example to others.