Feeling Firewall Friendly? Azure Virtual Machine Protection With NSGs Explained

Let's talk cloud security best practices for Azure - Microsoft's cloud. 

Do you like keeping the bad guys out? So do I...

That's why we'll take a look at Microsoft's Azure Cloud services. Most people are concerned that moving data and/or services to the cloud will create greater risk, from a security perspective.
But for a number of reasons, that is a misconception. A myth...

Done right, the cloud is usually much more secure than on-premise datacenters!

One of the reasons for this, at least as it relates to Azure, is that Azure has a firewall-like construct called a Network Security Group, or NSG, for short. An NSG is a set of inbound and outbound rules that allows (or denies) traffic into and out of a resource based on source IP/port or destination IP/port. They cannot limit ICMP traffic, but they can be set for either TCP, UDP, or both.

A resource that can "accept" an NSG being attached to it (and therefore defended by it) can be a virtual network card (NIC), a virtual machine (only to a classic VM), or a network construct like a subnet (and by extension all VM's that live within that subnet). See attachment points below.

Diagram of Azure NSG attachment points

With appropriate rules that deny all traffic EXCEPT the specific protocols on specific ports that you need for functionality or backplane management, your resources will be protected.

So because NSGs can be applied at several levels, you can quickly and easily build a mult-layered defensive shield to protect your computing resources. And perhaps best of all, creating and applying NSG's is totally free!

You can create one NSG and attach it at multiple points, or you can have a separate NSG for each attachment point. The fewer you create, the easier they are to manage, but then you have less granularity for applying specific rules to specific resources based on the function of that resource. The idea is to find the "management sweet spot".

In addition to NSG protection outside the VM, best practices definitely dictate we should be running a firewall within the O/S of the virtual machine itself. So if you do the math, with a "Classic" VM you can have 4 firewalls protecting a virtual machine.

On a Resource Manager VM (which is the newer type) they did away with applying NSGs at the VM level, and you apply it to either NICs attached to a VM, or to the entire subnet (which in turn applies that NSG to all VMs within the subnet).

So, if create multiple NSGs and attach them to all of the available attachment points, and turn on the O/S firewall, you'll have three layers of defense, and that doesn't count any other security appliances or NIPS, HIPS, or UTM systems that you likely will have in place.

Add some built-in DDOS protection that most major cloud service providers offer within their DNS services, and you'll have pretty good defenses, which is why I say that done right, cloud computing is MORE SECURE than on-premises computing.

And when you consider how easy it is to create, manage, and review NSGs compared to the good old days of TELNETing into a router to look at the ACL configuration, cloud security is much faster and easier.

One nice thing about working with NSGs is that the Azure management portal becomes your "single pane of glass" to manage your basic defenses.

However, you may have to use RDP or other tools to  manage the O/S based firewall.

NSGs are just one on many tools provided by Azure to make cloud computing more secure. This is a big topic, but in this blog post I'm just focusing on the simplicity of implementing NSG's.

Here's a link to learn more about Azure's NSGs and how to implement them following best practices.

The image below is to give you an idea of what a simple NSG might look like - just a few simple rules that are processed in order from the top down. You can create something like this without being a cloud security expert, so I encourage you to learn more at the link above.

Hacked: The True Confession of a Security Pro

Casting my ego aside for a moment: getting hacked can be a good thing. How? Well, it makes for a fantastic learning experience in several ways, which I'll share below. First, here's the back-story...

Not too long ago, a few of my WordPress blogs, managed by me and hosted on a small hosting company's shared servers (the economy plan), got hacked.  And not just once, but repeatedly.

Over the course of a month, every few days I'd get the dreaded email from the hosting support team that my site(s) were compromised, locked down by them to prevent the spread of infection, and that I needed to fix it.

The cleanup works was tedious. The configuration verification and back-end tweaking were time consuming. In those few weeks, I learned more about WordPress security than I wanted to know.

And despite my best efforts, it kept happening. I felt like a chump!

I tried everything they recommended: CloudFlare, premium hosting (where every WordPress install isn't share a common directory structure), numerous firewall and security plugins, blocking numerous IP addresses from countries that are notorious for hacking, locked down the .htaccess file, etc.

And in the end it was all for naught. I either wasn't cleaning out infected files properly, which would soon cause re-infection, or an unknown hack was getting through my defenses. And my hosting company wasn't much help.

Either way, it sucked. With enough time, I'm confident I could have solved the root cause, but after the 5th or 6th time, I was ready to walk away from being the administrative duties of the sites. Fortunately they were for small side projects that didn't have any major impact when they went down.

Lesson 1: After that experience, I can't say that I'm still a fan of (self-hosted) WordPress - I don't recommend it anymore, even though it has amazing flexibility and community open-source support.

What else did I learn? Lesson 2: that unless you truly  enjoy the burden of managing your infrastructure configuration, to opt instead to use Managed Services that someone else is responsible for!

Microsoft Azure's Shared Responsibility Model

In terms of cloud, this means going for SaaS over Paas, and PaaS over Iaas. With the "shared security" model that cloud providers use, they have SOME security responsibilities.

And the more they "own" the more they have to worry about security and patching. In the "highest level" SaaS model, the customer has almost NO security responsibility. The cloud provider takes on almost all of it!

This might explain the rise of SaaS software offerings, Identity as a Service offerings, and Serverless Computing. When someone else does the install, patching, maintenance, management, and protection of a system / server, you are relieved of that burden. It frees you to focus on what you love.

Of course, sharing the responsibility with a cloud provider is no guarantee you won't get hacked, so you have to make sure your infrastructure and websites are being consistently backed up, and that you have a restoration plan and incident response plan in place.

But with that said, transferring some of the risk and headaches to some other party is frequently worth the investment!

As a cloud security geek, I usually love security challenges. That's what I get paid for. But unless we have similar titles, I'm betting you DON'T love dealing with security. So the best security advice I can give you is hand off the challenge to someone else.

For example, did you notice this blog is on Google's Blogger platform, and not self-hosted WordPress? Sure, I don't get as many features, and I relinquish some control, but I also don't have to worry about securing my blog and the servers it runs on. That frees me up to focus on my employer's and clients' security issues, which suits me just fine!

To reduce your security and management headaches, use managed services whenever feasible, but make sure you don't abdicate your responsibility to ensure that the cloud provider is doing their job.

As a business owner or employee, you ALWAYS have overall responsibility and oversight for your security situation.

I hope this lands on some receptive ears. If so, please let me know your thoughts, struggles, or questions on this topic.

-Ryan

How Amazon Can Make AWS More Secure

As a certified AWS architect and SysOps engineer, I've spent a lot of time learning the ins and outs of cloud computing on their platform.

And in that time I've come to understand that done right, cloud computing on AWS is FAR MORE SECURE than most corporate implementations.

In my opinion, if you put in the same amount of time on AWS as you do for your on-premise network and app security, you'll be significantly more secure on AWS than you would be on your own datacenter!

Why? Because of the vast array of cutting edge security tools (both AWS-native and 3rd  party vendor apps and appliances) that offer deep and useful security insights that were just pipe dreams a few short years ago.

You owe it to yourself to go check them out.

I believe this "security is better in the cloud" stance holds true for Microsoft's Azure as well, which is a platform I am currently getting certified on, but back to AWS - I spotted a glaring and simple way that Amazon could make their security even better, and it relates to penetration testing and vulnerability scanning.

Penetration testing is widely understood to be one of the best ways to find security vulnerabilities before the bad guys do, and every organization should be doing it - regularly.

And yes, AWS let's you do penetration testing. However, it requires their approval first, and herein lies the problem. When I "subscribed" to a Sophos UTM 9 appliance that I wanted to learn, and use to do some scanning on my test network, I had to fill out a form. And in that process, I had to list out the hosts and the IP addresses of both the  scanning tool, and the scanner appliance, and list the times of the tests, etc.

This makes sense because AWS needs to (presumably) disable alarms and "reactive" technologies so you don't get shut down when they detect the scanning / pen testing taking place on their network.

BUT, this process could be significantly streamlined, and made much easier so that more customers commit the time and energy to conduct penetration tests.

In short, it was a clunky, time consuming process to fill out a form to request permission to do the scan.

I had to go look up I.P. addresses, and gather info on the specific instance ID's of my servers and list them out. And while not a horrible process, it definitely introduced "friction" and would discourage some people from bothering with the process in the first place. And that's not good.


A recent pen-test email confirmation from AWS

My recommendation (are you listening, Amazon?) is to allow cloud administrators to request port scanning by simply adding a checkbox next to the the instance names, so that all hosts to be scanned simply have their box checked. It would be easy to add a date/time feature where the admin could select a time window for scanning the "checked" hosts, etc. Let's call this an "in-line pen testing request".

My logic is that by reducing the amount of effort required to conduct pen testing on AWS, more customers would take advantage of this ability.

They could even "up the anty" by integrating this request with the products or appliances of some 3rd party security vendors, like Sophos, so security-conscious AWS customers could try out new tools with ease.

This could be a boon to those vendors, and give customers access to an array of tools that they are unfamiliar with.

I'm sure there are numerous other ways to facilitate pen testing on AWS, and I'd love to hear your ideas!

-Ryan

PS: If you have an Amazon account, here's the link to learn more about pen testing, and to submit the form to do your own penetration testing. Use it! Find (and fix) your network weaknesses, even if it's a clunky process.

PPS: If you know anyone inside Amazon who might like to hear this idea, please share the link with them.

You Paid for Endpoint Protection, But Is It Actually ON and Protecting You?

A report from Threat Stack came out recently that showed that a huge chunk of cloud-related security problems are caused by not doing the basics, such as ensuring your servers are patched on a regular basis.


From experience, I can tell you that this applies to non-cloud environments as well.

Along the same lines, I'd like to share about the importance of monitoring your endpoint protection tools and services running on your endpoints to make sure they are actually on! Seems like a no-brainer, doesn't it?

Yet I have worked for many organizations that run Windows desktops and rarely have I seen them use notification and monitoring tools (they are already paying for) to ensure that endpoints are continuously running the services that protect the endpoint. I do my best to fix that wherever possible, or at least bring the risks to the attention of higher level decision makers.

Is your defender even on the field?

Whether your endpoint protection is HIPS, HIDS, antivirus, or any other related service, if its running on the endpoint, it must STAY running in order to be effective. Pretty basic stuff.

Yet time and time again, I see system with basic protections turned off, and the end user and the organization they work for, are unaware of this. And that's when very bad things can happen

For example, users might be downloading risky files from the Internet, thinking that antivirus (A/V) scans are taking place, protecting them, determining what files are OK and which are malicious, when in fact they are not being scanned at all.

Keep in mind that most end users are not sophisticated enough to check to see what services are running on a Windows system, and even if they know how, why would they think to go look, if nothing seems amiss?  No pop-up warning = no problems, right? Wrong...

Granted, many endpoint protection software schemes are designed to prevent being turned off, either by the end user or by a malicious actor or malware. But what if that fails for whatever reason?

Ironically, you're probably paying for tools that have this monitoring capability built right on, but its likely you're failing to take advantage of these features.

Instead of providing a list of ways to programatically ensure that endpoint protection services are always on and running, I will ask you to analyze what services SHOULD be running, and what protections AND notifications you have in place to guarantee that they stay running.

Here are some ideas, tools, or approaches you can use to make sure endpoint protection mechanisms are actually on, all the time:

• Group Policy
• SCCM and other enterprise monitoring systems
• SIEM
• Startup Scripts
• Login Scripts
• Powershell

I recommend getting with your I.T. cohorts and brainstorming ways to ensure your endpoints are ALWAYS being protected, which will also ensure you're fully leveraging your investment in cybersecurity defenses.

Happy hunting!

-Ryan

What is AWS Shield & How Can It Save Your Website from DDoS Attacks?

The 3 Types of Attacks & Is It Worth Paying for Advanced DDOS Protection?

If you run a website that helps you turn a profit in business, then your website availability has a direct impact on your financial health. That's not news, but the number attacks against website availability are growing very quickly and getting more sophisticated every week, and every single website is a potential target.

Yours is no exception, so you must be proactive in defending your website's availability.

Now, notice I said "availability" as opposed to "uptime". Uptime is more a measure of a web server being on and running, which is from your internal perspective, but "availability" is from your external customers perspective. Just because your web servers are "up" and on doesn't mean that they're functional for your customers or end users.

And that's why Distributed Denial of Service(DDOS) attacks hurt you - they prevent your customers from resolving your domain name or URL to an I.P. address of your web servers.

If this happens, in the best case scenario, your site won't load. Worst case scenario, attackers redirect your URL to their own bogus servers, which at that point is a site hijack, not a DDOS attack, but that's a blog post for another day.

There are 3 types of DDOS attacks: Volumetric, meaning your servers get overwhelmed with DNS query traffic - drowned in a flood of DNS lookups.

Then there are Application Layer attacks, in which valid, but malicious, HTTP queries also overwhelm the server, causing it to not be able to respond to valid requests from real users.

And then there are State Exhaustion attacks, described by Amazon as "abuse of stateful protocols that causes stress on firewalls and load balancers by consuming large numbers of per-connection resources". Think "Ping of Death" attacks, which send very large chunk ping requests that overwhelm your servers.

Most attacks are volumetric: 60-68%, with the other two types each getting 16-20% of market share (depending on who is reporting the stats). It's a constantly evolving landscape of threats.

So how to prevent a DDOS attack? Well, start by realizing that you need to protect yourself from all three kinds of attacks. Yes, that's more work for you and for the security pros your employ or contract with. But now for some good news...

If you're a customer of Amazon AWS, and you host your static files on S3, or use Route 53 DNS services, then Amazon is already helping you, for free!

At re:Invent 2016, Amazon announced the roll out of AWS Shield which is a set of tools to help prevent DDOS attacks.

AWS Shield at the standard level of service is a free new tool from AWS that is "already on" helping to protect your site. According to Amazon "AWS Shield Standard will protect you from 96% of the most common attacks today, including SYN/ACK floods, Reflection attacks, and HTTP slow reads. This protection is applied automatically and transparently to your Elastic Load Balancers, CloudFront distributions, and Route 53 resources.”

But what about the other 4% of attacks, you ask? 

Well, you could upgrade to the Advanced (paid) level of shield, but that's where performing a risk/reward analysis comes into play.  

As a site owner, it's your responsibility to figure out what level of risk is acceptable to you, and how much you want to invest in reducing that risk. Failure to undertake this analysis is a failure that rests squarely on your shoulders, so don't avoid it.

How to properly perform risk analysis is too big of a topic to cover in this short article, but think about how much revenue comes in via your website.

Now imagine losing all that traffic for a day or two, and think about whether or not you are willing to risk that revenue.

For some companies, we could be talking about millions of dollars. And if advanced DDoS protection like Shield Advanced only costs you a couple of hundred dollars per month, then that's some pretty cheap insurance!

Here's how they describe the Advanced level of Shield "...provides additional detection and mitigation against large and sophisticated DDoS attacks, near real-time visibility into attacks, and integration with AWS WAF, a web application firewall."

It also provides "additional detection and mitigation against large and sophisticated DDoS attacks plus additional protection over AWS Shield Standard including intelligent DDoS attack detection for network layer (layer 3), transport layer (layer 4) and application layer (layer 7).  In addition, customers also get access to 24x7 DDoS response team during a DDoS attack and additional real-time metrics and reports. The advanced service also provides cost protection for your Elastic Load Balancing resources CloudFront and Amazon Route 53 hosted zones".

For more information about both level of AWS Shield and how they can help you against DDos attacks, here's the link to Amazon's official page about the new services:

And for more information on DDoS attacks and security threats in the wild, here's a link to Akamai's 2016 Q2 State of the Internet / Security report. it has more great stats and trends on these types of threats to your website, so it's worth reading.

-Ryan

Why I'm Obtaining my CCSK from the Cloud Security Alliance

Should you get your CCSK? Here's 5 reasons why I have decided to get mine:

The Cloud Security Alliance is on the forefront of cloud security. In their words, the CSA "is the world’s leading organization dedicated to defining and raising awareness of best practices to help ensure a secure cloud computing environment."

More info at https://www.udemy.com/csa-certificate-of-cloud-technology-security-knowledge-ccsk/learn/v4/overview

And to further that end, the CSA has been offering the Certificate of Cloud Security Knowledge (CCSK) since 2010, and it's popularity is growing. I'd like to share five reasons why I've decided to get this professional certification.

1: I love to be at the intersection of major trends. Cloud computing is "hot" and jobs are plentiful, and growing. Additionally, security is hot and security professionals are in demand too. So what could be more fun and HOT than being an expert in both cloud computing and cloud cybersecurity? The demand for cloud security experts will be fantastic, and because of the amount of training and education it requires, there isn't that much competition!

2: The CCSA has a rock solid reputation. When it comes to cloud security, because it's vendor neutral, the CCSK has a solid reputation as an authority on real-world cloud security frameworks and best practices, so if you're going to be in this field, this is the organization to align yourself with and to learn from.

3: It will speed up cloud adoption. One of the biggest concerns that EVERYONE has about cloud adoption is the perceived "security risk" it entails.  The way I see it, the more people who are experts at cloud security, the more cloud technologies will be adopted successfully, and I think overall that cloud adoption enables the potential for tremendous advancements for humanity. 

4: From a purely financial standpoint, its a great investment! If you're good at self studying, you can invest as little as the cost of taking the test (currently $345), and get a certification that could add hundreds of thousands of dollars to your income over the next 10-20 years. It's an excellent long-term career investment with a huge return on that investment (ROI). 

5: It will make you a better cloud architect, or DevOps engineer, or whatever type of I.T. you do. Having the body of knowledge required to achieve this certification will make me (and you) better at what we do. We'll be more competent, more well-rounded, and more security aware - and that can NEVER be a bad thing!

So if you're pursuing a career in cloud computing, I think you should strongly consider getting your CCSK certification. The training can be highly affordable too - I'm currently taking a course I found on Udemy.com that cost me all of $19 for 62 lectures constituting 9 hours of video training. More information on that course can be found HERE. 

I'd love to hear your reasons on why you have decided to get your CCSK, or have decided NOT to. Either way, share your thoughts!


Update 4/10/17  I am happy to report that I passed my test and I am now CCSK certified! 

Here's the proof! :-)

What's All This Talk About Two Factor Authentication (2FA) And Why Should You Have It to Protect Yourself?

What is 2FA And How Can It Help You Prevent Being Hacked?

It's only a matter of time before your email, Facebook, Twitter, or LinkedIn profile - really any social media profile - gets hacked. Not IF, but WHEN.

Let that sink in for a moment...

Logging in to any system usually involves a username and password. Think of that password as 1 form of authentication. What if you had to enter two passwords - would that be two-factor authentication?

No. Why not? Because it's not a different TYPE of authentication. 2FA is when you use two completely different types of authentication to significantly enhance your security posture. This is also sometimes referred to as MFA - multi-factor authentication.

What are some of the many forms of authentication?

• Something you ARE (such as your height, weight, or I.Q. score)
• Something you HAVE (a device, like a smart phone)
• Something you KNOW (such as a code or password)
• Something you DO (draw a design, or speak in your distinctive, unique voice)

So two-factor authentication is a simple technique that requires two different types of authentication to drastically improve your account security.

Get in the habit of using 2FA to protect your social media accounts

And fortunately, nearly every major social media service allows you to turn it on - using a smart code that is sent to your smart phone. At least, that's the easiest way to enable 2FA.

Sure it might force you to glance at your phone and type in a 6 digit code as part of the login process, but that's the point - a hacker won't have the code unless they have your smart phone!

Now you know. Turn it on. Use it. And avoid being hacked and all of the massive embarrassment that goes along with it!

I hope this was helpful. If so, say so in the comments!

PS: Don't let 2FA lull you into using weak passwords as your first form of authentication. Continue to use (or start using) strong, complex passwords, along with 2FA. Otherwise, you really only have 1.5FA, and that wouldn't be good.

PPS: Here's a link on how to enable 2FA on AWS

3 Things That Trailrunning and Cybersecurity Have in Common

I went for a fantastic trail run in the Boise foothills today after work. It's one of the many reasons I love Boise - you can be in the foothills within 10 minutes from my house, and it's one big hike and bike playground, and it's Spring!

Me, trailrunning in the Boise Foothills

As I was running off my winter beer belly, I realized that cyber-security and trailrunning have at least three things in common, and they are:

1: The tortoise beats the hare! Meaning that implementing and maintaining good security in the cloud is not a sprint, it's a marathon - be in it for the long haul! Don't sprint out of the gate, lose steam, and then stop improving your security posture because you got burned out. Small improvements day after day, over time, add up to excellent progress.

2: Pay attention to detail, or you might "twist an ankle". With trail running, if you don't watch where you put your feet, its easy to stumble, fall, or injure and ankle or knee. With cloud security, the same thing applies, but you'll injure your ability to accomplish your organizations goals. One misplaced comma, one bad ACL, or one misconfigured route table can shut down your production network, and possibly get you fired. So stay focused when you're making changes in security policy, or you could cause injury!

3: A little preparation goes a long way! With trail running, having adequate clothing, nutrition, and hydration can make a huge difference in how much you enjoy your trail run (or hate it). With cloud security, preparation is just as important. There are thousands of way to be prepared, but a few include...

• Staying aware of new threats and attack vectors
• Being crystal clear on your organizations goals as it relates to security practices
• Documenting your configurations in case you get hit by a bus, or get fired
• Staying on top of configuration management by having good policies and procedures
• Reviewing configurations for mistakes and errors before implementing that change in production

Those are just a few ways to be properly prepared, and they can make your task of improving your security posture MUCH more enjoyable, so don't just blindly go out there and start making changes to make your network more secure. Plan, prepare, review, and then proceed with confidence.

If you can think of any other ways in which cloud security is like trail running, I'd love to hear your comments. 

Stay fit, have fun, be secure, and I'll see you on the trails!

Amazon AWS Just Made It Easier to Create, Read, and Understand Security Policy Templates

Cybersecurity is challenging enough, but when one of the main tools you use to secure your resources is in a hard to interpret format, such as YAML or JSON, it makes it that much more challenging.

While these two formats are easier to read than code, its still far to easy to misinterpret. The consequences can be serious!

As you probably know, the root of creating effective cybersecurity within Amazon's AWS is the use of IAM - Identity and Access Management.

What is IAM? Basically its the tool you use to create users, roles and policies to control which users or roles have access to your resources, and under what conditions the access is granted or denied.

It basically forms the core plank in a sound AWS security strategy. It's the equivalent of Active Directory in a corporate network, at least the user/groups/roles component of Active Directory.

That's why I'm pleased to share that Amazon AWS has created a tool that displays IAM policies in a very clear and easy to read format - the Policy Summary tool, and it looks like this...

A portion of  an IAM Policy Template Summary

This will help minimize misconfigurations, mistakes, and errors that could leave you vulnerable.

Now you don't have to be a YAML or JSON expert to understand a policy, which can be created by you, or you can use one of AWS' preconfigured policy documents, and tweak it as you see fit depending on your custom needs.

To see policy summaries in your AWS account, sign in to the IAM console and navigate to any managed policy on the Policies page of the IAM console or the Permissions tab on a user’s page.

Below is a link to an article that discusses the Policy Summary tool that is available within AWS.
https://aws.amazon.com/blogs/security/move-over-json-policy-summaries-make-understanding-iam-policies-easier/

If you would like help or guidance on implementing a sound IAM strategy for your organization, don't hesitate to reach out via email or LinkedInhttps://www.linkedin.com/in/ryanaharris

Enjoy!