In IT, we know we need secure infrastructures. We even believe in security as a real thing – we do more than just give it lip service. We really try!
But sometimes security people make things difficult: they ask for too much, criticize too hard, and always preach the gospel of imminent doom.
As a long-time, part-time “security dude” myself, I’ve sometimes been in that role of doom preacher, and it’s no fun. But I found that having an open dialog with my co-workers about the concerns, risks, and strategies to mitigate those risks went a long way to getting everyone on the same page.
Today on Datanauts, we’re going to bust the security silo. Our guest, Jon Zeolla, is going to explain to us how to think about security in our data centers, and help us realize that security is not obstruction for its own sake.
We talk about framing security as risk management, and how security policies and practices must reflect your tolerance for risk. We also explore when and how to bring in the security team on new projects, and how non-security IT pros can become more security literate.
Jon is currently a member of a security team at a university, and also has experience in large financial and retail organizations. You can follow Jon on Twitter and check out his GitHub presence. If you’re in the Pittsburgh area, you can get together at a meetup.
This episode of Datanauts is brought to you by ITProTV. Enhance your technology aptitude. ITProTVis the resource to keep your I.T. skills up to date, with engaging and informative video tutorials. For a free 7-day trial and 30% off the life of your account, go to itpro.tv/datanauts and use the code DATANAUTS30.
Part 1 – Project Planning
- When planning an IT project, when is it time to bring in the security folks?
- Any time it has a large impact (visibility, heavily depended on, etc.). At a high level, security is risk management, but in order to make the right decision your security team needs to know what the landscape is like and needs to be involved early enough to guide the technical discussion from the security angle.
- Being involved in the planning stage can help architect a project to be more secure, similar to how knowing about a project that some non-IT department in the business wants to do before they go out and enlist shadow IT. If that happens, and then you need to bring something in-house, it’s a lot more painful than if they had just brought it to the IT team at the beginning.
- “Shadow IT is a term often used to describe information-technology systems and solutions built and used inside organizations without explicit organizational approval. It is also used, along with the term “Stealth IT”, to describe solutions specified and deployed by departments other than the IT department.”
- Are there different sorts of security concerns to be addressed, and will those involve different people? Infrastructure vs. physical vs. application, etc.?
- Security has a lot of different sub-disciplines, and a lot of this depends on your scale and company structure.
- In smaller shops you may have a SPOC (Security Point of Contact) who isn’t even a full time security person, and they will typically just handle the IT side of security.
- In medium sized shops (up to 500 or 1500 employees) you might have a security person. There’s two ways this can go – either a jack-of-all-trades type of person because they need to deal with all the different IT teams – or someone closer to an auditor or policy writer, who doesn’t get hands on with anything but instead documents and audits what should be happening in an org.
- In larger shops (Fortune 1000+) you can have whole groups of people divided up between a 24/7 SOC, an application-specific blue team, eDiscovery, Forensics, Incident investigators, data scientists, physical or electronic pen testers, etc. etc.
- In Internet-scale or highly secure environments, it’s a given that you will have some sort of security team, similar to larger shops, but I’ve also found that security is a bit more of the culture and even though there’s a security team, it’s everybody’s job to keep things safe.
- CSO (includes physical) vs CISO (information-focused).
- What does a security person do when they see a project moving ahead with an architecture they are uncomfortable with?
- Learn the history and get involved in the meetings, look at change review, etc. Really, they need to get in the loop and understand the current state and be informed of future changes to the plan. Depending on the risk tolerance for the project they may end up co-engineering or co-implementing the environment.
- Is security “everyone’s job”? If so, what does that really mean? Seems hard to pin down responsibility that way.
- The business owns it, the risk team communicates it, but the technical teams inform risk. In some places, risk and tech are the same. In others, risk tells technical the acceptable threshold. Combination of pen tests, vuln assessments, regular scans, validation against baselines, etc.
- Does having a firewall somewhere in a traffic flow mean an application is now secure? Of course not…but why not?
- Firewalls are good interim solutions, but there are service and protocol exploits. Some of the newer firewalls have been getting better at this, but they aren’t perfect and as they add complexity, they add attack surface for themselves. Also, most of these are signature based, and people have been able to bypass the protocol or service-specific identifications, which can sometimes give you the illusion of security.
- WAF (DB, Web, App tiers) can be helpful, but they can have the same problem as before. The obvious answer here is that you really need layers of security, and no one thing (firewalls) are going to solve your security issues.
- I’ve been in environments that don’t have a firewall (as a standalone appliance), and although it’s not optimal it’s still possible to raise the cost for an attacker to break in to the point where it doesn’t happen frequently. Of course, I would never say (even with all the money in the world) that it’s possible to make something “secure” and also available, it’s all about making it so oppressively hard to break into that it’s no longer worthwhile.
- There are plenty of ways around having a firewall (the standalone appliance) and still have a firewall, the service (remote-trigger black holing w/URPF, BGP FlowSpec, RPZ (Response Policy Zone) for DNS, etc.).
Part 2 – Risk Management
- One aspect of security is risk management. What are we getting at here?
- With every company there is a defined risk tolerance. It’s different between a university, finance company, or the government, and even within those verticals it can vary wildly. You need to have a grasp on what is considered reasonable to your upper management, and take the appropriate response. Your options are generally to transfer, accept, mitigate, or avoid the risk. This means you don’t always need to fix the problem itself, you just need to be aware of what’s going on and consciously make decisions.
- Is it correct to design an infrastructure for “security at all costs”?
- No, because there is no perfect security, so the cost would be infinite. This is a risk decision like everything else.
- What common issues does an organization simply “let go” rather than secure?
- This usually happens when one of two things happens. Either the issue is so hard to exploit, or it has such a minimal impact, that it is not worth the fix, especially if it’s a complicated change that requires a rearchitecture.
- The other situation is when the implementation of the security mechanism would delay a project in a way that impacts the customer or business unit. For instance, if it will delay a project from shipping by a month, and you are in a highly time sensitive market, the business may decide to accept the risk.
- This one is especially hard for many security people (myself included) to come to terms with, because we are here to protect the company. If the accepted risk becomes known publicly it could turn into a public relations or brand issue, it could turn into a lot of work for the incident response and other operational teams, and in some cases it can even bring an entire company down.
- It is possible in scenarios like this to transfer the risk instead of accepting it by buying insurance or something similar, but in a time crunch that’s not always possible because to get cyber insurance will frequently need to have audits done. What I’ve seen in talking with some cyber insurance companies in the past is that they can have their own models for how things should work, instead of using a standard like a DISA STIG, or a CISecurity benchmark, which means that you probably don’t already have it done when you start the conversation. And it will take more time to turn around the contract. And even if you do, the weaker your security protections are, the more you’re going to pay, so sometimes it’s better to go back to accepting the risk, and using the saved cost to mitigate potential issues in the future.
- Planning a security posture is one thing, but testing it later is another. How should security be verified later?
- Change management integration, periodic detailed reviews.
- Breach fatigue and phishing
- When a security problem is identified, how should IT react and work to resolve?
- Identify the risk, which is (somewhat controversially) identified as threat * vulnerability * impact. There are different ways to measure this, such as using – DREAD, CVSS, STRIDE, etc. However, you need to alter for your environment. This sets priority.
- Threat – Anything that can exploit a vulnerability, intentionally or accidentally, and obtain, damage, or destroy an asset.
- Vulnerability – Weaknesses or gaps in a security program that can be exploited by threats to gain unauthorized access to an asset.
- Impact (or Consequence) – The result of an unwanted incident.
- DREAD – Damage, Reproducibility, Exploitability, Affected Users, Discoverability
- STRIDE – Spoofing Identity, Tampering with Data, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
- CVSS – Common Vulnerability Scoring System
- Created by DHS with input from many companies including a subsidiary of CMU called the CERT/CC.
Part 3 – Becoming More Security Literate
- What advice do you have for someone interested in security as a profession?
- When economies grow they require increasing specialization. So, start as a generalist and solidify your technical foundation, and later in your career you can focus in on your one area and you’ll be way more effective. A lot of security is about understanding the big picture – being able to write an exploit is cool, but it’s way more cool when you know how to focus on the exploits which really matter in the grand scheme of things.
- In my opinion, people who don’t start in security are the best security engineers in the long term, because they ‘get it’ from the other side of the fence. They understand how the real world and how business works.
- For instance, sometimes you’ll see a conflict from what your vulnerability scanner is reporting, and what a sysadmin is telling you has happened regarding a recent patch. I’ve had to do this numerous times, where you log onto a server that’s telling you it’s entirely up to date, but when you do something like verify the actual version of a DLL that was supposed to be patched, you find that it’s still lagging behind due to an issue with the update software. If all you know is how to run a vulnerability scanner and tell someone what the output is, you’re not going to get the problem fixed, because (at least in my experience) the sysadmin is going to default to telling you that the scanner has a false positive, and go back to doing something else.
- Keeping up with the news is key too. Not just to see the new projects, technologies, and litigation, but to make sure that there isn’t a newly discovered and released vulnerability that affects you. There are plenty of materials out there to do this such as RSS or ATOM feeds, podcasts, and threat intelligence feeds.
- RSS feeds – New IETF RFCs,
- Podcasts – Risky Business, SANS Internet Storm Center, the cyberwire, Security Now, etc.
- Threat Intel – Various paid services, AlientVault, CrowdStrike, FireEye, Team Cymru (kum-ree), Critical Stack, etc. and some industry specific feeds from the ISACs (Information Sharing and Analysis Center) like FS-ISAC, REN-ISAC, or NH-ISAC.
- Are security certifications worth much?
- The knowledge should be the goal, and the certification the guide. I’ve done a bit of “certification collecting” in my past, but it was mostly because I just wanted to further my career and I didn’t have a predefined goal, so I used the certifications to keep myself growing broadly all across the security spectrum.
- Which security certifications are well-regarded by paper pushers?
- CEH, CISSP, Security+
- Which security certifications are well-regarded by security professionals?
- OSCP, OSCE, GIAC (SANS)
- What about conferences or user groups?
- BSides, DEF CON, Derby Con, CCC (Chaos Computer Club) in Europe. RSA for deep pockets and Black Hat for executives. The cool thing is all conferences are relevant.
- User groups – you should find whatever you have locally. There are things like ISSA, ISACA, OWASP, InfraGard, etc. which exist all over the place, but it mostly depends on how your local chapter is run. In my case, I opted to add another group into the mix locally because I wanted something that was a bit more hands-on and technical than what we already had established here.
- How can security people present to other IT teams about what they do, and help bust those silos?
- Still a good question!
PQ Show 78: BGP Flowspec For DoS Mitigation – Packet Pushers