<div dir="ltr"><a href="https://medium.com/starting-up-security/learning-from-a-year-of-security-breaches-ed036ea05d9b#.jautyh26y">https://medium.com/starting-up-security/learning-from-a-year-of-security-breaches-ed036ea05d9b#.jautyh26y</a><br><p name="1982" id="gmail-1982" class="gmail-graf gmail-graf--p gmail-graf-after--h3">This year 
(2016) I accepted as much incident response work as I could. I spent 
about 300 hours responding to security incidents and data breaches this 
year as a consultant or volunteer.</p><p name="383e" id="gmail-383e" class="gmail-graf gmail-graf--p gmail-graf-after--p">This
 included hands on work with an in-progress breach, or coordinating a 
response with victim engineering teams and incident responders.</p><p name="a461" id="gmail-a461" class="gmail-graf gmail-graf--p gmail-graf-after--p">These
 lessons come from my consolidated notes of those incidents. I mostly 
work with tech companies, though not exclusively, and you’ll see a bias 
in these lessons as a result.</p><h3 name="41e1" id="gmail-41e1" class="gmail-graf gmail-graf--h3 gmail-graf-after--p">Centralized logging makes everything better.</h3><p name="0a8a" id="gmail-0a8a" class="gmail-graf gmail-graf--p gmail-graf-after--h3">A theme in this article will be: “what separates standard incidents from horrifying nightmares?”</p><p name="69f4" id="gmail-69f4" class="gmail-graf gmail-graf--p gmail-graf-after--p">A
 good or bad story around logging will dictate the rest of the incident.
 I repeatedly find that audit logs are the backbone of all good security
 policy and effective incident response.</p><p name="b3b7" id="gmail-b3b7" class="gmail-graf gmail-graf--p gmail-graf-after--p">The
 first thing I do in any incident is understand how much I can depend on
 a victim’s logging infrastructure. The answer I receive will 
drastically change my experience and the success of the company. There’s
 a wonderful trend in CI/CD/DevOps culture where centralized logging and
 alerting is becoming a standard practice. I’ve become almost <em class="gmail-markup--em gmail-markup--p-em">entitled </em>to the expectation of rich data in any company formed in the last three years or so.</p><p name="e785" id="e785" class="gmail-graf gmail-graf--p gmail-graf-after--p">I
 recommend that any security or infrastructure team putting off a 
comprehensive approach to logging drop nearly everything to invest in 
it. This means getting all logs, from all hosts and applications, across
 all teams, into as few log destinations as possible.</p><p name="5188" id="gmail-5188" class="gmail-graf gmail-graf--p gmail-graf-after--p">Have a strong story around <a href="https://slack.engineering/syscall-auditing-at-scale-e6a3ca8ac1b8" class="gmail-markup--anchor gmail-markup--p-anchor" rel="nofollow" target="_blank">host</a>, application, authentication, and <a href="https://medium.com/@magoo/investigating-cloudtrail-logs-c2ecdf578911#.czbw75b5b" class="gmail-markup--anchor gmail-markup--p-anchor" target="_blank">infrastructure</a>
 logging that will inform your preventative work for years to come. 
Additionally, it assists other teams as they meet availability goals.</p><p name="facf" id="gmail-facf" class="gmail-graf gmail-graf--p gmail-graf-after--p"><em class="gmail-markup--em gmail-markup--p-em">Edit: </em>A gotcha —<a href="https://www.eff.org/deeplinks/2016/11/tech-companies-fix-these-technical-issues-its-too-late" class="gmail-markup--anchor gmail-markup--p-anchor" rel="nofollow" target="_blank"> be aware of user privacy in what you log, and how relevant long term storage would be in a breach</a>.
 Shortened retention periods to protect user privacy are common and 
would be in greater demand depending on a product you build.</p><blockquote name="f7b4" id="gmail-f7b4" class="gmail-graf gmail-graf--blockquote gmail-graf-after--p">Conclusion: Prioritize well decorated, accessible, centralized and <a href="https://summitroute.com/blog/2016/11/22/how_to_write_security_alerts/" class="gmail-markup--anchor gmail-markup--blockquote-anchor" rel="nofollow" target="_blank">alert-able</a>
 logs above most other security projects. An idea for an alert should 
easily land in production within 10 minutes or so, if done right.</blockquote><h3 name="2680" id="gmail-2680" class="gmail-graf gmail-graf--h3 gmail-graf-after--blockquote">You might not find the root cause of a breach.</h3><p name="4521" id="gmail-4521" class="gmail-graf gmail-graf--p gmail-graf-after--h3">More than one incident I worked this year went through to completion without ever finding a root cause.</p><p name="72c2" id="gmail-72c2" class="gmail-graf gmail-graf--p gmail-graf-after--p">This
 is a nightmarish experience for victims who have to meet with their 
leadership and executives to describe their mitigation efforts which are
 not guided by data. Containment becomes an incomplete and “best effort”
 problem.</p><p name="a4a2" id="gmail-a4a2" class="gmail-graf gmail-graf--p gmail-graf-after--p"><em class="gmail-markup--em gmail-markup--p-em">With</em> a root cause, a mitigation plan sounds something like:</p><blockquote name="05ba" id="gmail-05ba" class="gmail-graf gmail-graf--pullquote gmail-graf--startsWithDoubleQuote gmail-graf-after--p">“We wipe this laptop, replace that server, roll a single credential.”</blockquote><p name="c5ca" id="gmail-c5ca" class="gmail-graf gmail-graf--p gmail-graf-after--pullquote"><em class="gmail-markup--em gmail-markup--p-em">Without</em> a root cause, it sounds more like like:</p><blockquote name="1a3b" id="gmail-1a3b" class="gmail-graf gmail-graf--pullquote gmail-graf--startsWithDoubleQuote gmail-graf-after--p">“We wipe <strong class="gmail-markup--strong gmail-markup--pullquote-strong">ALL</strong> the laptops, replace ALL the servers, roll ALL the credentials.”</blockquote><p name="45cd" id="gmail-45cd" class="gmail-graf gmail-graf--p gmail-graf-after--pullquote">The
 discovery of a root cause is an important milestone that dictates the 
emotional environment an incident will take place in, and whether it 
becomes unhealthy or not.</p><p name="e8e0" id="e8e0" class="gmail-graf gmail-graf--p gmail-graf-after--p">A
 grey cloud will hover over a team until a guiding root cause is 
discovered. This can make people bad to one another. I work very hard to
 avoid this toxicity with teams. I remember close calls when massive 
blame, panic, and resignations felt like they were just one tough 
conversation away.</p><p name="f51f" id="gmail-f51f" class="gmail-graf gmail-graf--p gmail-graf-after--p">No matter whether you’re big or small — it’s important to role-play a crisis every so often.</p><blockquote name="4dff" id="gmail-4dff" class="gmail-graf gmail-graf--blockquote gmail-graf-after--p">Conclusion: Practice regular table tops and <a href="https://medium.com/starting-up-security/red-teams-6faa8d95f602" class="gmail-markup--anchor gmail-markup--blockquote-anchor" target="_blank">red team exercises</a>.
 Treat random bug bounty or vulnerability disclosures as full blown 
practice incidents. Practice scenarios where you are not in control, you
 are not omniscient, the right log doesn’t exist and talent can’t 
understand an issue. Fight from the ground every now and then with your 
team.</blockquote><h3 name="6ab6" id="gmail-6ab6" class="gmail-graf gmail-graf--h3 gmail-graf-after--blockquote">Persistent attackers will target homes.</h3><p name="0716" id="gmail-0716" class="gmail-graf gmail-graf--p gmail-graf--startsWithDoubleQuote gmail-graf-after--h3">“Bring your own device” is often used to categorically describe the risk employees bring to an organization. This <strong class="gmail-markup--strong gmail-markup--p-strong">does not</strong> well characterize the direct attacks happening against individuals within organizations.</p><p name="c224" id="gmail-c224" class="gmail-graf gmail-graf--p gmail-graf-after--p">This
 year’s incidents involving APT groups notably focused their attacks 
directly on employee’s personal emails and endpoints. Whether they show 
up at the office with their personal devices won’t matter if they’re 
sharing credentials or access tokens on personal accounts and devices, 
or accessing corporate accounts from home.</p><p name="8a31" id="gmail-8a31" class="gmail-graf gmail-graf--p gmail-graf-after--p">Understanding
 lateral movement from an employee’s home to corporate assets is 
incredibly hard. Manual follow up with employees was the primary area of
 investigative friction on numerous occasions. A common trend was shared
 passwords acquired from attacks on personal accounts and devices that 
were not used on a corporate network, but hosted credentials that were 
relevant.</p><p name="34e8" id="gmail-34e8" class="gmail-graf gmail-graf--p gmail-graf-after--p">Additionally
 (this fell into “zero root cause”) one incident in particular was 
highly suggestive of an engineer potentially storing sensitive 
credentials in their own personal cloud infrastructure to debug 
production infrastructure remotely.</p><p name="1ff3" id="gmail-1ff3" class="gmail-graf gmail-graf--p gmail-graf-after--p">Logs
 weren’t available in the time window we needed to guide us. We had 
heard that attacks were pointed at senior developers in the months that 
preceded the attack, but the investigative workload on personal employee
 systems would have been too blind and expensive to follow through with 
without some kind of lead to start with.</p><blockquote name="6c16" id="gmail-6c16" class="gmail-graf gmail-graf--blockquote gmail-graf-after--p">Conclusion:
 Find ways to improve your employees security practices at home. 
Subsidize their use of a password manager, MFA hardware, or anything 
else you can. Push hard for them to involve your security team even if 
they have personal security issues or see bad behavior while off-duty. 
Teach and enable them to protect their families from threats as well.</blockquote><h3 name="584a" id="gmail-584a" class="gmail-graf gmail-graf--h3 gmail-graf-after--blockquote">Bitcoin is targeted, even if you store none.</h3><p name="fd70" id="gmail-fd70" class="gmail-graf gmail-graf--p gmail-graf-after--h3">Platform
 companies are often compromised with the assumption that they may have 
access to, or integrate with, a bitcoin company. Please refer to the <a href="https://magoo.github.io/Blockchain-Graveyard/" class="gmail-markup--anchor gmail-markup--p-anchor" rel="nofollow" target="_blank">Blockchain Graveyard</a> for more information on this trend, or this public example from <a href="https://sendgrid.com/blog/phishing-attack-rocks-the-btc-community/" class="gmail-markup--anchor gmail-markup--p-anchor" rel="nofollow" target="_blank">SendGrid’s blog</a>:</p><blockquote name="3543" id="gmail-3543" class="gmail-graf gmail-graf--blockquote gmail-graf-after--p">Conclusion:
 If you deeply rely on a partner’s technology, find a way to heavily 
manage that risk. If you’re a bitcoin company, practice extreme paranoia
 and take extraordinary measures in limiting the access of your 
partnerships.</blockquote><h3 name="d560" id="gmail-d560" class="gmail-graf gmail-graf--h3 gmail-graf-after--blockquote">Sophistication follows humiliation.</h3><p name="3ce8" id="gmail-3ce8" class="gmail-graf gmail-graf--p gmail-graf-after--h3">Many
 breach announcements this year pointed to a “sophisticated attacker” as
 a narrative of their issue. This usually is followed up by criticism 
when an initial means of their compromise is revealed.</p><p name="8e0d" id="gmail-8e0d" class="gmail-graf gmail-graf--p gmail-graf-after--p">Most breaches begin with spear phishing, commodity exploits, a leaked key, or some other obvious or preventable detail.</p><p name="563d" id="gmail-563d" class="gmail-graf gmail-graf--p gmail-graf-after--p">However,
 this is almost never the “sophisticated” aspect of a breach worth 
talking about. It’s easy to point at an embarrassing vector and dismiss 
the rest of an attack.</p><p name="da20" id="gmail-da20" class="gmail-graf gmail-graf--p gmail-graf-after--p">Thus,
 do not judge an adversary by the vector they’ve chosen. An adversary 
may show you what “sophistication” means after advancing from their 
beachhead.</p><p name="7d6a" id="gmail-7d6a" class="gmail-graf gmail-graf--p gmail-graf-after--p">For
 instance, while an initial vector may not be notable or interesting, 
the access or credentials an attacker has from a separate platform 
compromise may reveal a lot about how motivated and capable they were in
 targeting you.</p><p name="2296" id="gmail-2296" class="gmail-graf gmail-graf--p gmail-graf-after--p">As a public example: Would Lockheed describe <a href="https://www.scmagazine.com/rsa-confirms-lockheed-hack-linked-to-securid-breach/article/559000/" class="gmail-markup--anchor gmail-markup--p-anchor" rel="nofollow" target="_blank">their breach in 2011 as sophisticated</a>?
 Even if their adversary came prepared with stolen RSA SecureID data… If
 it started with a spear phish, does that somehow mean the adversary is 
no longer intimidating?</p><blockquote name="a520" id="gmail-a520" class="gmail-graf gmail-graf--blockquote gmail-graf-after--p">Conclusion:
 “Sophisticated” attackers don’t flex their muscles on the initial 
intrusion effort. Don’t underestimate initial lame attacks against you 
as unsophisticated, an adversary will always exert minimum effort. That 
run-of-the-mill spear phish might be followed up with a new 0Day for all
 you know.</blockquote><h3 name="43c5" id="gmail-43c5" class="gmail-graf gmail-graf--h3 gmail-graf-after--blockquote">Manage your secrets and keys.</h3><p name="82cd" id="gmail-82cd" class="gmail-graf gmail-graf--p gmail-graf-after--h3">Management of secrets was a big differentiator at victim companies.</p><p name="ebc5" id="ebc5" class="gmail-graf gmail-graf--p gmail-graf-after--p">I
 wasn’t roped into a single intrusion this year at any companies with 
completely role driven environments where secrets were completely 
managed by a secret store.</p><p name="08ed" id="gmail-08ed" class="gmail-graf gmail-graf--p gmail-graf-after--p">This
 can either mean one of a few things: These environments don’t exist at 
all, there aren’t many of them, or they don’t see incidents that would 
warrant involving IR folks like myself.</p><p name="9626" id="gmail-9626" class="gmail-graf gmail-graf--p gmail-graf-after--p">Keys
 stored in source code, leaked into cloud logging platforms, kept 
insecurely on employee endpoints or personal devices, or copy pasted 
into gists and pastebin were all a consistent theme for me this year. 
Insecurity of secrets were both obvious root causes, or deeply 
exacerbated a breach once obtained by an adversary.</p><blockquote name="ae85" id="gmail-ae85" class="gmail-graf gmail-graf--blockquote gmail-graf-after--p">Conclusion:
 Look into AWS roles, avoid putting secrets into source code, keep real 
secrets away from developers, and be able to roll them quickly and 
often.</blockquote><h3 name="997b" id="gmail-997b" class="gmail-graf gmail-graf--h3 gmail-graf-after--blockquote"><span class="gmail-markup--quote gmail-markup--h3-quote gmail-is-other" name="anon_408b802a973b">Credential theft is still the lowest hanging fruit.</span></h3><p name="81b8" id="gmail-81b8" class="gmail-graf gmail-graf--p gmail-graf-after--h3">Several
 incidents still occurred at organizations with pretty healthy messaging
 avoiding password re-use, especially with senior executive leadership. 
This awareness messaging ultimately does not matter when considering 
personal accounts, if not directly messaged to employees.</p><p name="b94b" id="gmail-b94b" class="gmail-graf gmail-graf--p gmail-graf-after--p">While
 awareness efforts may delay the inevitable quite well, it was much more
 effective to see credentials managed behind an identity provider and 
Single Sign On integrations into their cloud products. I have not 
responded to any incidents where MFA was broken within an enterprise 
identity solution.</p><p name="e913" id="e913" class="gmail-graf gmail-graf--p gmail-graf-after--p">When
 Single Sign On integration is not an option, finding the MFA options in
 each product, and enforcing them, is also a major mitigation step. A <a href="https://help.github.com/articles/requiring-two-factor-authentication-in-your-organization/" class="gmail-markup--anchor gmail-markup--p-anchor" rel="nofollow" target="_blank">special shout out to GitHub is necessary</a>,
 as teams frequently store secrets in source code that can be protected 
by enforced, team wide MFA until better secret storage options are 
agreed upon by a team.</p><h3 name="85b7" id="gmail-85b7" class="gmail-graf gmail-graf--h3 gmail-graf-after--p">Insider threats have some patterns.</h3><p name="e87c" id="e87c" class="gmail-graf gmail-graf--p gmail-graf-after--h3">The
 smallest minority of issues I worked this year involved insider 
threats. Each insider issue was within a known range of motives which 
I’ve seen for several years now, 2016 being no exception.</p><p name="0aa7" id="gmail-0aa7" class="gmail-graf gmail-graf--p gmail-graf-after--p">The
 first involves people who heavily identify with Silicon Valley startup 
culture and are incredibly aggressive in approaching the press to drive 
attention to their current or future company.</p><p name="1a12" id="gmail-1a12" class="gmail-graf gmail-graf--p gmail-graf-after--p">Specifically, you can use the insider threat model of:</p><blockquote name="5632" id="gmail-5632" class="gmail-graf gmail-graf--pullquote gmail-graf--startsWithDoubleQuote gmail-graf-after--p">“<em class="gmail-markup--em gmail-markup--pullquote-em">If I leak something to the tech press now, maybe they’ll write about my tech startup idea later</em>”</blockquote><p name="1272" id="gmail-1272" class="gmail-graf gmail-graf--p gmail-graf-after--pullquote">While this is a fairly specific model, employees at tech companies <em class="gmail-markup--em gmail-markup--p-em">really</em> like leaking IP and product information for all kinds of outcomes.</p><p name="73d1" id="gmail-73d1" class="gmail-graf gmail-graf--p gmail-graf-after--p">This
 is common enough to consider a trending type of insider threat. This is
 tough to defend against as these are usually employees that don’t need 
much trust to leak with. It’s very hard to give prevention advice that 
applies broadly and doesn’t encourage a locked down, Apple-esque company
 at the same time. Most CEO’s want to be transparent to their employees 
and accept this risk.</p><p name="b7d3" id="gmail-b7d3" class="gmail-graf gmail-graf--p gmail-graf-after--p">The second pattern I’ve seen is around internal customer support tools. Once you hit a certain number of employees with access to administrative tools, an outlier employee is bound to commit fraud, or collude with others to do so.</p><h3 name="9342" id="gmail-9342" class="gmail-graf gmail-graf--h3 gmail-graf-after--p">Measure and eliminate your debt.</h3><p name="eff4" id="eff4" class="gmail-graf gmail-graf--p gmail-graf-after--h3">Nearly all of the organizations I assisted this year had an outlier area of staggering technical debt.</p><p name="5b23" id="gmail-5b23" class="gmail-graf gmail-graf--p gmail-graf-after--p">This
 leads me to believe that companies that consider “debt” as part of 
engineering process are usually highly disciplined organizations, with 
lower risk.</p><p name="ed8a" id="ed8a" class="gmail-graf gmail-graf--p gmail-graf-after--p">Here’s why: A startup can move fast. They can cut corners. They can compete aggressively and take risks.</p><p name="1f56" id="gmail-1f56" class="gmail-graf gmail-graf--p gmail-graf-after--p">During
 development and a successful launch, a difference from one company to 
the next is how well they’ve documented the shortcuts and have had a 
“retrospective” on what their debt level has become.</p><p name="12e3" id="gmail-12e3" class="gmail-graf gmail-graf--p gmail-graf-after--p">Then they pay back their debts.</p><p name="5cdc" id="gmail-5cdc" class="gmail-graf gmail-graf--p gmail-graf-after--p">Rarely do I see a team eliminate <em class="gmail-markup--em gmail-markup--p-em">all </em>of their debt, but the organizations that <em class="gmail-markup--em gmail-markup--p-em">at least</em> respect their debt never get so far behind that they can no longer be helped in a breach.</p><p name="ffd9" id="gmail-ffd9" class="gmail-graf gmail-graf--p gmail-graf-after--p">Debt
 comes in many forms: scale, development speed, site reliability, 
customer churn, manual work before automation, and security.</p><p name="2837" id="gmail-2837" class="gmail-graf gmail-graf--p gmail-graf-after--p">The problem is that security debt is <em class="gmail-markup--em gmail-markup--p-em">silent</em>.
 Every other form of debt causes errors, customer complaints, expenses, 
and engineer rage. Security debt only results in breaches and is near impossible to quantify. It requires manual effort or a technology harness to surface security debt.</p><p name="5ae7" id="gmail-5ae7" class="gmail-graf gmail-graf--p gmail-graf-after--p">An
 engineering organization that has a mastery of its debt is rare as a 
company and, as a symptom, an easy-to-secure organization.</p><p name="7bd8" id="gmail-7bd8" class="gmail-graf gmail-graf--p gmail-graf-after--p">I’ve
 rarely seen this in practice, but the mere desire of this level of 
enlightened engineering is a great sign at a company. Google is a 
company that has structured its “error debt” around its release 
practices and has policies driven around it, and is one of the best examples I’ve found of making “debt” an objective problem to be measured and solved. <a href="https://twitter.com/owhitehouse93" class="gmail-markup--anchor gmail-markup--p-anchor" rel="nofollow" target="_blank">Ollie Whitehouse</a> @ NCC Group has also <a href="https://www.nccgroup.trust/uk/our-research/software-security-austerity-security-debt-in-modern-software-development/" class="gmail-markup--anchor gmail-markup--p-anchor" rel="nofollow" target="_blank">presented on this topic</a> in the past.</p><p name="9032" id="gmail-9032" class="gmail-graf gmail-graf--p gmail-graf-after--p">Most
 engineering organizations don’t know that some of their basic processes
 (retrospectives, post mortem) are helping them avoid massive areas of 
debt.</p><blockquote name="85ca" id="gmail-85ca" class="gmail-graf gmail-graf--blockquote gmail-graf-after--p">Conclusion: Make sure your biggest debts are paid before moving along to another large endeavor.</blockquote><h3 name="b3ad" id="gmail-b3ad" class="gmail-graf gmail-graf--h3 gmail-graf-after--blockquote">Conclusion</h3><p name="f9f6" id="gmail-f9f6" class="gmail-graf gmail-graf--p gmail-graf-after--h3 gmail-graf--last">We
 have the most to learn from our security incidents. It’s important to 
find ways to talk about them and learn from them. If you’re involved 
with incident response, I hope you can too!</p><br></div>