Category Archives: Blog Posts

Infrastructure-as-Code Is Still *CODE*

After working in a DevOps environment for over a year, I’ve become an automation acolyte. The future is here and I’ve seen the benefits when you get it right: improved efficiency, better control and fewer errors. However, I’ve also seen the dark side with Infrastructure-as-Code (IaC). Bad things happen because people forget that it’s still code and it should be subject to the same types of security controls you use in the rest of your SDLC.

That means including automated or manual reviews, threat modeling and architectural risk assessments. Remember, you’re not only looking for mistakes in provisioning your infrastructure or opportunities for cost control. Some of this code might introduce vulnerabilities that could be exploited by attackers. Are you storing credentials in the code? Are you calling scripts or homegrown libraries and has that code been reviewed? Do you have version control in place? Are you using open source tools that haven’t been updated recently? Are your security groups overly permissive?

IaC is CODE. Why aren’t you treating it that way?

devops_borat

Tagged , , , , , ,

NTP Rules of the Road

There’s nothing more infuriating than watching organizations screw up foundational protocols and NTP seems to be one of the most commonly misconfigured. For some reason, people seem to think the goal is to have “perfect” time, when what is really needed is consistent organizational time. You need everything within a network to be synchronized for troubleshooting and incident management purposes. Otherwise, you’re going to waste a lot of energy identifying root causes and attacks.

It’s recommended to use a public stratum one server to synchronize with a few external systems or devices at your network perimeter, but this should only be configured if you don’t have your own stratum zero GPS with a stratum one server attached. I can’t tell you how many times I’ve seen a network team go to the trouble to set this up and the systems people still point everything to ntp.org.

Everything inside a network should cascade from those perimeter devices, which is usually a router, Active Directory system or stratum one server.  This design reduces the possibility of internal time drift, the load on public NTP servers and your firewalls, and the organizational risk of opening up unnecessary ports to allow outgoing traffic to the Internet. Over the last few years, some serious vulnerabilities have been identified in the protocol and it can also be used as a data exfiltration port by attackers.

In addition to the IETF’s draft on NTP “best practices,” the SEI also has an excellent guidance document.

While it’s not realistic to have your own stratum zero device in the cloud, within AWS, it is recommended to use the designated NTP pool specified in their documentation.

Oh, and for the love of all that is holy, please use UTC. I cannot understand why I’m still having this argument with people.

Tagged , , , , ,

Security Group Poop

One of the most critical elements of an organization’s security posture in AWS, is the configuration of security groups. In some of my architectural reviews, I often see rules that are confusing, overly-permissive and without any clear business justification for the access allowed. Basically, the result is a big, steaming pile of security turds.
While I understand many shops don’t have dedicated network or infrastructure engineers to help configure their VPCs, AWS has created some excellent documentation to make it a bit easier to deploy services there. You can and should plow through the entirety of this information. But for those with short attention spans or very little time, I’ll point out some key principles and “best practices” that you must grasp when configuring security groups.
  • A VPC automatically comes with a default security group and each instance created in that VPC will be associated with it, unless you create a new security group.
  • “Allow” rules are explicit, “deny” rules are implicit. With no rules, the default behavior is “deny.” If you want to authorize ingress or egress access you add a rule, if you remove a rule, you’re revoking access.
  • The default rule for a security group denies all inbound traffic and permits all outbound traffic. It is a “best practice” to remove this default rule, replacing it with more granular rules that allow outbound traffic specifically needed for the functionality of the systems and services in the VPC.
  • Security groups are stateful. This means that if you allow inbound traffic to an instance on a specific port, the return traffic is automatically allowed, regardless of outbound rules.
  • The use-cases requiring inbound and outbound rules for application functionality would be:
    • ELB/ALBs – If the default outbound rule has been removed from the security group containing an ELB/ALB, an outbound rule must be configured to forward traffic to the instances hosting the service(s) being load balanced.
    • If the instance must forward traffic to a system/service outside the configured security group.
AWS documentation, including security group templates, covering multiple use-cases:
Security groups are more effective when layered with Network ACLs, providing an additional control to help protect your resources in the event of a misconfiguration. But there are some important differences to keep in mind according to AWS:
Security Group
Network ACL
Operates at the instance level (first layer of defense)
Operates at the subnet level (second layer of defense)
Supports allow rules only
Supports allow rules and deny rules
Is stateful: Return traffic is automatically allowed, regardless of any rules
Is stateless: Return traffic must be explicitly allowed by rules
We evaluate all rules before deciding whether to allow traffic
We process rules in number order when deciding whether to allow traffic
Applies to an instance only if someone specifies the security group when launching the instance, or associates the security group with the instance later on
Automatically applies to all instances in the subnets it’s associated with (backup layer of defense, so you don’t have to rely on someone specifying the security group)
Additionally, the AWS Security Best Practices document, makes the following recommendations:
  • Always use security groups: They provide stateful firewalls for Amazon EC2 instances at the hypervisor level. You can apply multiple security groups to a single instance, and to a single ENI.
  • Augment security groups with Network ACLs: They are stateless but they provide fast and efficient controls. Network ACLs are not instance-specific so they can provide another layer of control in addition to security groups. You can apply separation of duties to ACLs management and security group management.
  • For large-scale deployments, design network security in layers. Instead of creating a single layer of network security protection, apply network security at external, DMZ, and internal layers. 

For those who believe the purchase of some vendor magic beans (i.e. a product) will instantly fix the problem, get ready for disappointment. You’re not going to be able to configure that tool properly for enforcement until you comprehend how security groups work and what the rules should be for your environment.

aws_poop

Tagged , , , , ,

Apple, I Wish I knew How to Quit You

My baptism into the world of computers occurred the Saturday my dad brought home an Apple IIc when I was a kid. He was always fascinated by electronic gadgets and this seemed to be the latest device that would sit in a room (and eventually gather dust) next to his ham radio and photography equipment.  The damn thing didn’t do much, but it still felt magical every time I had the opportunity to play games on it; that funky beige box with a square hunk of plastic on a leash moving an arrow around a screen. At the time, it didn’t feel like anything more than a fancy toy to me. I certainly had no idea that this interaction would foreshadow my own love-hate relationship with the entire technology industry.

Years later, I turned into an Apple acolyte while working in the IT department of an East Coast university. I was an MCSE and had become thoroughly exhausted battling Windows drivers and the BSOD circle of Hell.  After I moved to Unix administration, the first version of OS X felt like a relief after long days of command line combat. While it had an underlying CLI that worked similarly to the Unix platforms I was used to, Apple provided a more stable desktop that was painless for me to use. Unlike Windows, the hardware and the OS generally seemed to work. Sure, I didn’t have all the software packages I needed, but virtualization solved that problem. While I lost some of my expertise in building and fixing personal computers, I no longer seemed to have any interest in tinkering with them anymore. During a mostly effortless, decade-long relationship with Apple, I would jokingly tell friends, “Buy a Mac, it will make you stupid.”  I became an evangelist, “Technology is just a tool. Don’t love the hammer, love what you can make with it.”

But as often happens in romances, this one has hit a rocky patch. Lately, trusting the quality of Apple products feels akin to believing in Santa Claus, honest politicians or a truly benevolent God.

The relationship started to flounder about 6 months ago, when I was unlucky enough to have the hard drive fail in my 2013 27″ iMac. It had been a workhorse, but the warranty had expired a few months before and I was in the unwelcome position of choosing between options ranging from bad to worse. I could try to replace it myself, but after looking at the IFIXIT teardown, that idea was quickly nixed. The remaining choices were to pay Apple or buy a new system between release cycles.  After running the cost/benefit analysis in my head the last option made the most sense, since the warranties on both of my laptops were also expired. With some trepidation, I purchased the newly redesigned 2016 MacBook Pro with an external LG monitor. And here’s where my struggles began.

Within a few days of setting up the laptop, I noticed some flakiness with USB-C connections. Sometimes external hard drives would drop after the system was idle. In clamshell mode, I often couldn’t get the external monitor to wake from sleep. I researched the issues online, making recommended tweaks to the configuration. I upgraded the firmware on my LG monitor, even though the older MacBook Pro provided by my workplace never had any issues. Then I did what any good technology disciple would do and opened a case with Apple, dutifully sending in my diagnostic data, trusting that Support would cradle me in their beneficence. The case was escalated to Engineering with confirmation that it was a known timing issue to be addressed by a future software or firmware patch. In the meantime, I refrained from using the laptop in clamshell mode and got used to resetting the monitor connection by unplugging it or rebooting the laptop. I also bought a dock that solved my problems with external hard drives. Then I waited.

Like the rest of the faithful, I watched last week’s WWDC with bated breath. I was euphoric after seeing the new iMac Pro and already imagining my next purchase. But a few days later, after having to reset my external monitor connection four times in a 12-hour period, I emailed the Apple Support person I had been working with, Steve*, for a status update on the fix for the issue with my MacBook Pro. I happened to be in Whole Foods when he called me back and the poetic justice of arguing over a $3000.00 laptop in the overpriced organic produce aisle wasn’t lost on me.

Support Steve: Engineering is still working on it. 

Mrs. Y.: What does that mean? Do you know how long this case has been open? I think dinosaurs still roamed the earth.

Support Steve: The case is still open with Engineering.

Mrs. Y: If you’re releasing a new MacBook Pro, why can’t you fix mine? Is this a known issue with the new laptops as well? If not, can’t you just replace mine?

Support Steve: That isn’t an option.

Mrs. Y: Please escalate this case to a supervisor.

Support Steve: There’s no supervisor to escalate to. Escalation goes to engineering, I only have a supervisor for administrative purposes.

Mrs. Y: I want to escalate this case to the person you report to, because I’m not happy with how it’s being handled.

Then the line went dead.

While Support Steve never raised his voice, for the record, a polite asshole is still an asshole.

This experience has done more than sour me on Apple, it’s left me in a full-fledged, technology-induced existential crisis. How could this happen to me, one of the faithful? I follow all the rules, I always run supported configurations and patch my systems. I buy Apple Care!

I even considered going the Hackintosh route. But I don’t know if I can go back to futzing with hardware, praying that a software update won’t make my system unusable. And Apple’s slick hardware still maintains an unnatural, cult-like hold over me.

So, like a disaffected Catholic, I continue to hold out hope that Apple will restore my faith, because it’s supposed to “Think Different” and be the billion-dollar company that cares about its customers.  But I can’t even get anyone to respond on the Apple Support Twitter account, leaving me in despair over why my pleas fall on deaf ears.

brokeback_apple

*I’m not making this up, the Apple Support person’s name is actually “Steve.” But maybe that’s what they call all their support people as some kind of homage to the co-founder.

Tagged , , ,

When Security Pros WannaCry

Once again the Internet is set to DEFCON level:OH SHIT due the latest ransomware, WannaCry. I’ll refrain from any further analysis of the malware, since it’s already been discussed ad nauseam by every major security vendor. But I will offer the following thoughts.

WTF?! Why is the industry still so bad at dealing with malware? This attack paralyzed organizations like the NHS and impacted carbon units (you know, those things who pay us) in almost 100 countries. But even as the Internet was melting down, organizations were still sluggish to test and apply this patch after it was released.

“In healthcare and other sectors we tend to be very slow to address these vulnerabilities,” says Lee Kim, the director of privacy and security at the Healthcare Information and Management Systems Society.

According to Brian Krebs, Microsoft released a patch for the vulnerability in March 2017, “…but organizations running older, unsupported versions of Windows (such as Windows XP) were unable to apply the update because Microsoft no longer supplies security patches for those versions of Windows.” Woah Nelly, ORGS ARE STILL RUNNING CRITICAL SYSTEMS ON WINDOWS XP?! That OS was released in 2001 and most people don’t even drive cars that old.

And what about all those NextGen security products that are supposed to address zero days? Where was that super-fantastic, heuristic, machine learning AI when we needed it?

The depressing thing about fighting malware is that the most effective solutions are the same as they were a decade ago:

  1. Make sure you’re running an endpoint security product with updated signatures, formerly referred to as antivirus.  Do these programs negatively impact system performance? Oh yeah. Are they foolproof? Hell no. But like a screen door, they filter out the majority of attacks.
  2. Patch and update your devices like it’s 1999.* If you’re running Windows, install the official patch (MS17-010), which closes the affected SMB Server vulnerability used by the attack. Microsoft even released a patch for those unsupported versions of Windows. 

*That’s another Prince reference, in case you missed it.

doves_cry_malware

Tagged ,

Chicken Little Security

It’s been one of those weeks in information security. The kind that makes me think about raising sheep in New Zealand, because they won’t argue with me about APTs and attribution. In addition to the Java/SMTP/FTP vulnerability that has vendors scrambling, I’ve suffered through trying to explain the following:

While I could probably break each of these down and explain how the sky really isn’t falling, I think Val Smith said it best recently:

Are you able to get an accurate inventory of your network?
Can you rebuild any system, anywhere, in less than a day?
Can you push software and configuration changes, including patches, remotely?
Do you have tested backups?
Do you have enough IT/DevOps to keep your environment stable?
Do you have a tested IR plan?
Do you have proven data sources (logs, netflow, full pcap, endpoint telemetry)?

If you answered no to any of those questions, you probably shouldn’t be too worried about SHA collisions. 

Here endeth the rant.

sha-asif

Tagged , ,

Fear and Loathing in DC

Lately it takes a very compelling request to get Mrs. Y to leave the Sanctum Sanctorum and give a talk, but what better topic is there than digital defense? I love the smell of FUD in the morning, whipping people up into a frenzied paranoia, then watching them rush out of the room to get prepaid cell phones and put duct tape over their web cams.

In all seriousness, no matter which side of the political fence you inhabit, no one can argue that government surveillance is at an all-time high. I can’t even get the Security SOC Puppets together in the same room anymore, because they’re demanding a Faraday cage on their contract rider. So I’m happy to offer my perspective and some guidance to help the general public (i.e. nerd-challenged) protect themselves from snooping and digital attacks.

Special thanks to the the former (recovering) attorney and activist who organized the event.

If you don’t trust Slideshare, you can download the presentation here.

Tagged , , ,

Booth Babe Shame

Yesterday on Twitter I came across the following in my feed:

Screenshot 2016-06-23 13.46.05

I was horrified and angry, responding with the following:

Screenshot 2016-06-23 14.05.41

I also posted something similar on Linkedin, Facebook and Google+.  I never heard from the vendor, but I did hear back from some pretty offended men and women, both technologists and non-technologists.

Screenshot 2016-06-23 14.15.34

Why are we still having this conversation? Why would ANY vendor think it’s appropriate to make make the staff at a technical conference dress like employees at Hooters?

There’s a bitter irony in reading article after article about improving the diversity in STEM fields and then seeing this. I’m getting pretty tired of feeling like a second class citizen in this industry. I’d like to be able to go to a conference and know that I’ll be treated with the respect due a senior-level technologist, not minimized because I happen to have a uterus. Clearly, I’m not the only person who feels this kind of behavior is no longer acceptable and shouldn’t be tolerated. I encourage anyone equally appalled to call out the vendor in question. If we can’t appeal to their morals, maybe they’ll think twice if it impacts their bottom line.

UPDATE: I’ve been corrected regarding the venue. This event took place at a Vegas night club, but I’m STILL offended. I don’t see any Booth Bros. Why did this vendor feel the need to have women promote their product this way?

UPDATE 6/28: Looks like people at Nutanix are embarrassed, but I’m not sure if this will actually translate to any awareness on their part.

“In a blog post Friday, Julie O’Brien, vice president of corporate marketing at Nutanix, apologized for the stunt while also offering an explanation of what went wrong.”

This was in my feed this morning: Nutanix CMO After Risque Conference Stunt: I Will Resign If It Happens Again.

 

Tagged , ,

Fixing a Security Program

I’m still unsettled by how many security programs are so fundamentally broken. Even those managed and staffed by people with impressive credentials. But when I talk to some of these individuals, I discover the key issue. Many seem to think the root cause is bad tools. This is like believing the only thing keeping you from writing the Next Great American novel is that you don’t have John Steinbeck’s pen or Dorothy Parker’s typewriter.

In reality, most of the problems found in security programs are caused inferior processes, inadequate policies, non-existent documentation  and insufficient standards. If buying the best tools actually fixed security problems, wouldn’t we already be done? The truth is that too many employed in this field are in love with the mystique of security work. They don’t understand the business side, the drudgery, the grunt work necessary to build a successful program.

For those people, here’s my simple guide.  I’ve broken it down to the following essential tasks:

  1. Find your crap. Everything. Inventory and categorize your organization’s physical and digital assets according to risk. If you don’t have classification standards, then you must create them.
  2. Document your crap. Build run books. Make sure you have diagrams of networks and distributed applications. Create procedure documents such as IR plans. Establish SLOs and KPIs. Create policies and procedures governing the management of your digital assets.
  3. Assess your crap. Examine current state, identify any issues with the deployment or limitations with the product(s). Determine the actual requirements and analyze whether or not the tool actually meets the organization’s needs. This step can be interesting or depressing, depending upon whether or not you’re responsible for the next step.
  4. Fix your crap. Make changes to follow “best practices.” Work with vendors to understand the level-of-effort involved in configuring their products to better meet your needs. The temptation will be to replace the broken tools, but these aren’t $5 screwdrivers. Your organization made a significant investment of time and money and if you want to skip this step by replacing a tool, be prepared to provide facts and figures to back up your recommendation. Only after you’ve done this, can you go to step 6.
  5. Monitor your crap. If someone else knows your crap is down or compromised before you do, then you’ve failed. The goal isn’t to be the Oracle of Delphi or some fully omniscient being, but simply more proactive. And you don’t need to have all the logs. Identify the logs that are critical and relevant and start there: Active Directory, firewalls, VPN, IDS/IPS.
  6. Replace the crap that doesn’t work. But don’t make the same mistakes. Identify requirements, design the solution carefully, build out a test environment. Make sure to involve necessary stakeholders. And don’t waste time arguing about frameworks, just use an organized method and document what you do.

Now you have the foundation of any decent information security program. This process isn’t easy and it’s definitely not very sexy. But it will be more effective for your organization than installing new tools every 12 months.

 

Tagged , , , , , , , ,

Security Word of the Day: Compromise

Living in Washington DC, many of my friends and acquaintances work for the federal government in some capacity. And not all of these people are in IT. When you live in this area, politics seem to permeate everything, making House of Cards seem more like reality television than fiction.

I know a former congressional staff member and when we run into each other, inevitably our conversations turn to the current state of the federal government. It’s obligatory here, sort of like chatting about the weather anywhere else. Recently she made the point that recent problems with government shutdowns and standoffs could be attributed to one major problem: confusing compromise with capitulation. The government only works when both sides are willing to negotiate and unsophisticated, inexperienced politicians generally fail to differentiate between the two concepts, causing no end of problems.

I realized this is also a major problem with many information security professionals. At least 50% of our work is focused on discussing and negotiating risk. Does Operations really need to apply that emergency patch to all 2500 servers today to mitigate the latest threat? Is there an active exploit? What about the risk of service interruption? Can it be done in phases?

Often, our relationship to the organization turns into a WWE Main EventInformation Security vs. the Business. But like effective politicians (no, it’s not always an oxymoron),  good security professionals pick their battles, living to fight another day. Compromise is not the same as capitulation and it doesn’t mean we’ve surrendered to the Dark Side when we work with the business to build reasonable timelines for remediating risk.

patching

%d bloggers like this: