CIS Control 2 on Azure - Application Whitelisting

Continuing on from the first post to chat about CIS Control 2, lets now have a look at 2.7: Utilize Application Whitelisting.  In the context of CIS, this references that application whitelisting is in use on all assets to ensure that only authorized software executes and all unauthorized software is blocked from executing on assets.

In the terms of Azure, I think the closets thing to software would be the Azure resources that one can deploy.  In this case, we want to be able to white list the Azure resources that can be deployed, and block all others.

It turns out that doing this via Azure policy is actually quite easy.  Here is an example:

{
  "if": {
    "field": "type",
    "notIn": [
      "Microsoft.Compute/VirtualMachines",
      "Microsoft.Compute/disks",
      "Microsoft.Compute/networkInterfaces"
    ]
  },
  "then": {
    "effect": "audit"
  }
}

The above policy (as written) will throw an audit even when a resource is deployed that is not of the listed types.  Using Azure Policy effects, one could switch the result to deny, which would then enforce that no resource types that were not previously approved could be deployed.  Building out a policy such as this would likely satisfy the application whitelisting control of CIS Control 2.

CIS Control 1 on Azure - Maintain Asset Inventory Part 5

In part 4 we discussed how we could use an Azure function (presumably triggered off of an event hub subscription) that would look at a resource and grab information on the required tags.  Another way to do this is to make use of Azure Policy.

The policy document for this type of affair is quite easy and looks something like this:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
      },
      {
        "anyOf": [
          {
            "field": "tags.department",
            "exists": "false"
          },
          {
            "field": "tags.approved",
            "exists": "false"
          },
          {
            "field": "tags.owner",
            "exists": "false"
          }
        ]
      }
    ]
  },
  "then": {
    "effect": "audit"
  }
}

The above policy will only look at virtual machines, and will kick off a non-compliance item if any of the tags department, approved, or owner is missing.  Pretty neat!  One thing to keep in mind when using this system is the evaluation triggers.  See this link for more information.

Setting up Wordpot on MHN

I have been working on using my Azure subscription to set up a honey pot network of difference sensors that i can fool around with.  The goal of this article is to talk a bit about setting up wordpot on MHN.

If you don't know, MHN or the Modern Honeypot Network, is a pretty cool project put on by ThreatStream.  You can find out more info:  https://github.com/threatstream/mhn

One pretty cool thing I've noticed so far is that MHN makes it extremely easy to setup and configure new sensors, by providing scripts to automate the installation and base configuration.

One of the first sensors I wanted to play around with is wordpot.  Wordpot is essentially a wordpress emulator that allows you to build configurable plugins based on specific input calls.  I will likely fool around with customizing this later on, but for now I just wanted to get the initial sensor going.

After setting up a blank ubuntu 16.04 box, it was remarkably simple to get wordpot configured up.  Navigating to the deploy > Ubuntu - Wordpot in my MHN server gave me a pre-built script that took care of the rest. 

Something like:

wget "http://<your server>/api/script/?text=true&script_id=13" -O deploy.sh && sudo bash deploy.sh http://<your server> <your key>

And that was it.  Wordpot connected up and I can now see my sensor in my sensors tab.



I decided to test out a couple of attacks against my sensor.  They showed up in the attacks tab.



One thing I noticed is that there is a serious lack of information in the attacks tab. I know that something happened, but not what (no packet, or anything like that).  This is something I will have to learn more about in the future (how to aggregate the logs, etc).

Wordpot itself has two log files that gave me some insight into what was going on.

The first was /opt/wordpot/logs/wordpot.log which gives me detailed information about the attacks. 



The second is the /opt/wordpot/wordpot.out which seems to contain a detailed log of the network traffic against the site.



That middle entry above represents the first request (not from me) against the server.  10 minutes after server deployment.  I guess that is about average!