- In the event of a breach or an infringement of your companies responsibilities, timely and appropriate escalation is required.
- During one breach I witnessed at a company I used to work for, inappropriate and untimely escalation made the situation a lot worse; the dev team and their managers failed to escalate a serious issue (users credentials being logged in a log file) quickly and appropriately, and as result the situation escalated.
- access to files is often logged. In the case of a breach, the lower the number of people who accessed the compromised resources the smaller the aftermath (e.g in the case of sensitive data being logged to a file, it’s easier to deal with five people who accessed the compromised file, than thirty). Reducing initial propagation helps this.
Once data leaves your system, your ability to control it rapidly diminishes. However there are steps you can take to mitigate risks:
- Only giving clients the data they require
- For example, with a centralized service application this would involve analyzing what each client needs, and applying logic so that they only receive that information.
- Actively engaging with client teams, asking them about security, guiding them. Even though the data has left your system, it is still your data and you need to ensure others are being careful with it.
- Systems often accidentally reveal their workings and vulnerabilities:
- Revealing the server/component type and version in their error response -this allows the attacker to search for known vulnerabilities against that version number.
- Logging full stack traces, or worse showing them in the error response -again, this tells the attacker what libraries the system uses, and if any of those libraries have known vulnerabilities, the attacker can exploit this.
- Just because your client is internal and not ‘user facing’ don’t assume that your error responses won’t filter through to the outside -in a highly distributed system, you never know where your response will end up.
- Same goes for logging; you don’t know who will end up reading your error logs.
- Basic Action Points For A Team:
- Never log full stack traces, unless absolutely necessary.
- Confirm that non of your responses contain information about the server products you use or their versions.
- Good visualization and graphing can expose suspicious activity.
- Tools like Datadog are invaluable when coupled with appropriate queries/visualization.
- Care with configuration. Misconfiguration is one of the top 5 reasons behind companies getting hacked.
- For sensitive data and functionality, consider incorporating a per-role based permissions system to reduce risk, and help track what happened in the event of an attack.
- Principle of least privilege again helps secure a system; a leaked password isn’t any use if there is no way to invoke important processes with it.
Infosec requirements should be determined during requirements gathering and where relevant integrated into JIRA tickets as infosec non-functional requirements.
I recently had the honour of presenting a talk at OWASP London at Bank in London. The talk was originally aimed at my company’s ground troops (developers, product managers), but also clearly presents a way of organising a security team; this may sound trivial, but the way a security effort is organised has a big impact on how effective it is. My current project (about 120 people across seven teams) has approached this by nominating security champions in each team, who manage risks using their own separate, cross team project (to avoid workflow issues), and having a unified ‘Security Council’.
The presentation was warmly received, and a number of good questions were asked, so it’s worth viewing the Q&A!
We’ve all been there.
We’re busily going about our work, when suddenly we notice something odd. Maybe it’s a badly thought out permission policy, maybe it’s some unprotected URL configuration that could be used to get an EC2 instance to spill its guts , but whatever it is, it smells.
But you’re knee deep in your own task, so you wearily go to JIRA, click ‘Create New’ and enter in the most perfunctory ticket description possible. And off it goes, your new little ticket, to reside deep within the project backlog, collecting crust with the other non-function-requirement tickets. Hey, business is business, and business needs features!
Or maybe you don’t do anything at all. ‘Cause why bother?
Either way, the problem never gets looked at, never gets evaluated and never gets fixed.