Forgiveness or Permission?

┌──(insider@thread)-[~]
└─$ cat summary.txt

Defensive professionals were more inclined in their answers to ask for forgiveness, and described taking calculated risks based on the cost of inaction.

Offensive professionals, such as pen testers, were more cautious of the negative impacts they could have on systems and the consequences of operating outside of the law.

Incident Response Consultant

I’ve learned over time to go with forgiveness over permission.

I think it really depends on the company that you are working for and how fast internal processes within a company are working. Cybersecuity operations side of things is about timely response. If your processes are slow, as long as you’re not breaking any laws and impacting massively, sometimes you might have to ask for forgiveness.

Give an example?

Say you need to review a draft report and the client really expects it because its time sensitive, and the people who are supposed to review are all on leave. You might just release it as a draft. Make sure it is caveated. If changes need to be made, you make it before you issue the final deliverable. But at least you give something to the client something to digest and prepare and a bit of an idea of what they can expect in the final report.

Why has that changed over time?

I think a lot of it was about confidence and understanding what you are doing, and the limitations. There are clear red lines that you can’t cross. As a consultancy, you can’t put the company at risk. If you release a report that is not appropriately caveated, and the client relies on information that is inaccurate, that increases the risk of liabilities.

Security Engineer

I think there is a balance here. I come from a position of technical development. I love building things. From that point of view, I find it a bit stifling when you have a great idea, but maybe the organisation's not ready for it. Maybe it needs to go through some levels of approval or maybe even if it is a good idea, they just don't think it's the right time.

Those kind of situations sort of give you a desire to be like, I'll just do it and seek approval later. But organisations have compliance and and change processes for a reason. You need to be careful about what you are deploying into your environment. If everyone was able to take a cowboy approach, go and build whatever they wanted, you could end up with vulnerabilities, shadow IT or holes in your defences that you weren't aware of.

It needs to be loose enough that you have that ability for creativity. You have that ability for people to come up with proposals that maybe a bit outside the box, maybe something you haven't thought of and they could really benefit the organisation. But also, there does need to be some level of oversight and management of the whole process.

Web App Tester

I'm going to say permission. I wouldn’t say that in most cases, but with pen testing, I think the risk of legal consequence is a little too high.

We are set a very strict scope, and we are told what we can and cannot do, and we are told what we have to ask about. If anything is even marginally outside of that or there is a chance that I could break something the client could get very upset and pursue legal consequence.

There are laws against hacking websites when you're not allowed, and these are laws can be enforced with jail time. So, you do not want to step outside those bounds.

What what steps do you take to make sure you're within the lines?

I am very particular about my scope. If I get a scope and the URL is even slightly different or there is a domain that's not included I will go and check.

What damage could you cause to an application?

You would be surprised what damage you can cause to an application. If there's a chance that it could cause harm or it could get somewhere that it's not supposed to, I just stop. It's usually things with SQL injection. SQL injection can get really weird, really quickly. You can find out perhaps information that you should really shouldn't have. Once I've found it, I will stop. I will email the client and ask if they want me to continue.

I do know of someone who sent off an automated Burp scan and deleted a back end database. That's not to say don't use Burp scan. It was a very badly implemented web app that never should have been pen tested. But it is an example of what can be done with something that you think is completely safe.

SIEM Engineer

I would say forgiveness. Either we have had a small incident and something had to be done and we just couldn’t wait for permission.

Isolating a few machines, just do it, rather than having something potentially spread. Take a calculated risk, if it is a core part of the business.