Provisioning & Hardening a Secure Server with Sicura & Terraform

We hear a lot about “shifting security left.” When talking to customers or listening to a conference talk, there’s a ton of emphasis right now on moving security checks as early in the timeline of the software development life cycle as possible.

The earlier we find a vulnerability, the cheaper and easier it is to fix, alleviating downstream risk and headaches, and it helps continuously improve our software development practices. The farther left we move our security checks, the “harder” the attack surface of our servers, and the fewer opportunities an attacker can find to compromise our servers.

From the IT or DevOps perspective, provisioning a new server is literally the farthest left you can get. It’s the very start of security.

Sicura’s security, compliance, and remediation platform was designed ​​by DevOps engineers to save IT teams' time and keep organizations secure. Built on an open-source core with a decade of NSA & community development, we know that that left-most step in the pipeline is critical to ensure compliance is never an afterthought.

Let’s take a look at how building with Sicura in your existing pipelines allows you to lock down new servers automatically. We’ll look at this both in terms of what’s happening and what jobs are running on your system.

Server Provisioning, Hardening, and Deployment via Pipeline

In this scenario, we’re talking about a human interacting with a piece of technology — let’s call him Joe. Joe is a commodities trader. He logs into a web application to make trades on behalf of his clients and company. When he logs in and makes those trades, he makes those groups a lot of money. It is very important to Joe’s bank that when he logs into the app, it works quickly and efficiently. IT must support Joe’s ability to log into that app and use it.

Pipelines run left to right, but to understand what’s happening at the leftmost stage, you have to look at what’s on the farthest right. The end of a pipeline is production. “Production” is where things happen — where money is generated and humans are interacting with technology.

This app requires a lot of power so that it can continue to run. Tens or hundreds of servers support the trading app.

Joe logs in on a Tuesday morning to the app, along with thousands of other traders using the same app. The system has 60% of the total server capacity for the trading app are in use. This is too large of usage — it could result in delays for Joe logging in and making trades, costing his bank and clients. This triggers the creation of new servers to deliver more capacity based on downstream demand.

The Pipeline — whether it’s GitLab Travis, Circle CI, Jenkins, Bamboo, or another tool (doesn’t matter for Sicura, we’re agnostic) — hears “need more servers” and triggers a server provisioning tool like Terraform.

Stage 1: Provision a new server
      Job 1 - Pick a server image
      Job 2 - Trigger Terraform to build
      Job 3 - Validate build

Terraform sits all the way to the left of the pipeline. Terraform is very simple, and is excellent in its simplicity. Its job is to take nothing and turn it into a server. Terraform doesn’t care about Joe. All it cares about is taking some preset builds from RedHat or Windows that it’s been told to duplicate, and creating exact duplicates.

Now you’ve got a server, a blank canvas. It is neither secure nor compliant. This is where Sicura comes in. Sicura is deployed to that blank canvas and applies the compliance policies that the financial institution has elected to follow to that canvas. In this example, let’s say Joe’s company follows the CIS benchmarks. Sicura enforces those benchmarks by applying the specific technical controls, which have been translated to code, to the server via Puppet or Bolt.

Stage 2: Harden the new server
       Job 1 - Enforce - apply all of CIS controls onto this server (run Puppet, or Bolt)
       Job 2 - Validate - CIS scan , STIG scan
      Job 3 - Report - for auditing purposes, save scan results into repository

The server is 96% CIS compliant. That compliance is validated with an assessment and the results are stored in a repository management tool like Jira or ServiceNow. Sicura stays on the server for continuous assessment and enforcement.

Stage 3: App Install
      Job 1 - Install app
      Job 2 - Validate & smoke test

Now the server is created and secured, and the trading app can be deployed on the new server. The Pipeline installs the application and does some validation to ensure it’s working. A smoke test involves triggering something and ensuring the app responds the way it is supposed to, just making sure what’s happening is what should happen.

Stage 4: Deploy New Hardened Server
      Job 1 - Deploy Server into Production
      Job 2 - Light validation

Finally, it’s time for the server to do what it was created to do. It’s deployed into an active state — either in the cloud or at a physical data center. Next time Joe clicks a button to execute a trade, there’s an additional server that’s managing some of the capacity, reducing overall capacity usage and making sure his trades happen as fast as they should.

Because the bank runs a sophisticated IT infrastructure, all of this happened automatically in a Pipeline — the only human who ever interacted with the process was Joe.

This provisioning process works nearly identically in legacy and modern infrastructures. The only change is that if an issue arises on a server once it’s in production, a team managing legacy infrastructure would try to fix the server by changing the settings to get it back to functional, whereas the team managing modern ephemeral architecture kill it and deploy a brand new server to replace it.

Building Sicura into your existing pipelines means your new servers start secure and stay secure, and are continuously compliant with the policies your organization is bound by.

If you're interested in integrating Sicura into your IT pipelines, get in touch.