A colleague of mine recently quiped, "'The perimeter' in AWS is actually defined by Identity and Access Management (IAM)." After some reflection, I think my colleague is spot on.
There can be times when you're working on the AWS Cloud where you need to grant limited access to your account to a third-party. For example:
- A contractor or a specialist needs to perform some work on your behalf
- You're having AWS Professional Services or a partner from the Amazon Partner Network do some work in your account
- You're conducting a pilot with AWS and you want your friendly neighborhood Solutions Architect to review something
In each of these cases you likely want to grant the permissions the third-party needs but no more. In other words, no granting of
AdministratorAccess policies because it's easy and just works. Instead, adherence to the principle of least privilege.
This post will describe two methods—IAM users and IAM roles—for proving limited access to third-parties.
In a previous post, I reviewed what a public subnet and Internet Gateway (IGW) are and that they allowed outbound and inbound connectivity to instances (ie, virtual machines) running in the AWS cloud.
If you're the least bit security conscious, your reaction might be, "No way! I can't have my instances sitting right on the Internet without any protection".
Fear not, reader. This post will explain the mechanisms that the Amazon Virtual Private Cloud (VPC) affords you to protect your instances.
Cisco Encrypted Traffic Analytics (ETA) sounds just a little bit like magic the first time you hear about it. Cisco is basically proposing that when you turn on ETA, your network can (magically!) detect malicious traffic (ie, malware, trojans, ransomware, etc) inside encrypted flows. Further, Cisco proposes that ETA can differentiate legitimate encrypted traffic from malicious encrypted traffic.
The immediate mental model that springs to mind is that of a web proxy that intercepts HTTP traffic. In order to intercept TLS-encrypted HTTPS traffic, there's a complicated dance that has to happen around building a Certificate Authority, distributing the CA's public certificate to every device that will connect through the proxy and then actually configuring the endpoints and/or network to push the HTTPS traffic to the proxy. This is often referred to as "man-in-the-middle" (MiTM) because the proxy actually breaks into the encrypted session between the client and the server. In the end, the proxy has access to the clear-text communication.
Is ETA using a similar method and breaking into the encrypted session?
In this article, I'm going to use an analogy to describe how ETA does what it does. Afterwards, you should feel more comfortable about how ETA works and not be worried about any magic taking place in your network. ?
Whether it's Dropbox, LinkedIn, MySpace, PlayStation, or whatever the latest breach happens to be, it's almost inevitable that you will be caught up in one of these breaches and have your username, password and possibly other information exposed in a data dump. Here's how to respond when that happens.
There's a lot of information on the intertoobs about getting ssh-agent "working" in OS X and even more articles about when and how the stock behavior of ssh-agent changed (mostly with respect to how ssh-agent interacted with the Keychain).
This article doesn't cover or care about any of that.
This article is concerned with:
- Enabling ssh-agent in such a way that I can "ssh-add" in one terminal window and that same agent (and the loaded keys) is available in all of my other terminal windows.
- Enabling use of ssh-agent from MacPorts and/or Homebrew and not the older ssh-agent that OS X ships with in /usr/bin.
- To avoid having to put my keys in the Keychain (just a matter of preference).
I'm a big fan of Let's Encrypt (free, widely trusted SSL certificates) but not a big fan of most of the client software available for requesting and renewing certificates. Unlike a typical certificate authority, Let's Encrypt doesn't have a webui for requesting/renewing certs; everything is driven via an automated process that is run between a Let's Encrypt software client and the Let's Encrypt web service.
Since the protocols that Let's Encrypt uses are standards-based, there are many open source clients available. Being security conscious, I have a few concerns with most of the clients:
- Complication. Many of the clients are hundreds of lines long and unnecessarily complicated. This makes the code really hard to audit and since this code is playing with my crypto key material, I do want to audit it.
- Elevated privilege. At least one of the clients I saw required root permission. That's a non starter.
I wanted to jot down some quick notes relating to running a virtual Firepower sensor on ESXi and how to validate that all the settings are correct for getting traffic from the physical network down into the sensor.
Firepower is the name of Cisco's (formerly Sourcefire's) so-called Next-Gen IPS. The IPS comes in many form-factors, including beefy physical appliances, integrated into the ASA firewall, and as a discrete virtual machine.
Since the virtual machine (likely) does not sit in-line of the traffic that needs to be monitored, traffic needs to be fed into the VM via some method such as a SPAN port or a tap of some sort.
The oft-requested and long awaited arrival of TACACS+ support in Cisco's Identity Services Engine (ISE) is finally here starting in version 2.0. I've been able to play with this feature in the lab and wanted to blog about it so that existing ISE and ACS (Cisco's Access Control Server, the long-time defacto TACACS+ server) users know what to expect.
Below are five facts about how TACACS+ works in ISE 2.0.
I've been doing a lot of reading and video watching on securing industrial control and automation systems (ICAS) (sometimes referred to as SCADA systems) so this POI has a few links related to that and ends with a link to an editorial piece about privacy and why privacy matters to us all.
Presenter: Craig Williams (@security_craig) - Sr Technical Leader / Security Outreach Manager, Cisco TALOS
"I'm from Talos. We love to stop bad guys."
- 1.1 million incoming malware samples per day
- 1.5 billion Sender Base reputation queries per day
Talos has a serious amount of data. For serious.
I don't believe this is well known: Cisco IOS has Role Based Access Control (RBAC) which can be used to create and assign different levels of privileged access to the device. Without RBAC there are two access levels in IOS: a read-only mode with limited access to commands and no ability to modify the running config (also called privilege level 1) and enable mode with full administrative access. There is no middle ground; it's all or nothing. RBAC allows creation of access levels somewhere between nothing and everything. A common use case is creating a role for the first line NOC analyst which might allow them to view the running config, configure interfaces, and configure named access-lists.
Cisco's Identity Services Engine (ISE) is a powerful rule-based engine for enabling policy-based network access to users and devices. ISE allows policy enforcement around the Who?, What?, and When? of network access.
- Who is this user? A guest? An internal user? A member of the Finance department?
- What device is the user bringing onto the network? A corporate PC? A Mac? A mobile device?
- When are they connecting? Are they connecting to the secure network during regular business hours or at 02:00 in the morning?
These questions can all be answered easily within ISE and are all standard policy conditions that are relatively easy to implement. In the post below I'm going to focus on the How? — How is the user or device connecting to the network? Asked another way, the question is Wired? or Wireless?
This post is for anyone who administers a Juniper SSL VPN. I saw an issue in our environment recently that was created by an unexpected interaction between two different systems that were working to enforce our computer security policy. Because the way the systems were configured is pretty common and because the issue is not specifically warned against by Juniper, I'm going to share it here.