Secure Deployment of a Web Hosted Application within a Cloud Computing Environment

Mike Badeaux, CISSP-ISSMP, CISA, CEH

Director of Service Operations & INFOSEC, DHI

October 7, 2014

Agenda• Introduction & DHI overview• Setting the stage

• Deployment/migration scenario• Disclaimers!

• Understanding the debate • Business benefits of a cloud hosting arrangement• Available cloud hosting options

• Control options• Network/host layer controls• Logging / “Instrumentation” / SIEM / Monitoring• Operational control considerations• Vuln/Pen testing options

What’s a “DHI?”

• Dice Holdings, Inc. • “Leading websites for professional communities”

• Translation: Job boards across multiple industries

• Serial acquirer• Tremendous growth, both organically and through acquisition

My life story…

Cliff Notes version:• In the security game for 20+ years• Used to having clearly defined boundaries around what it

is that I have to secure

• DISCLAIMER:• I am NOT a cloud security expert; I’m just someone who has gone

through a cloud migration recently, so I have a story to share• If you have information to enhance the detail here, please share it! • Add flavor or ask questions at any time

My comfort zone: Ca. 1994

My comfort zone: Ca. 2008

My discomfort zone: Ca. 2013

Cloud models defined• Collocated/outsourced infrastructure model (AKA “Hosting

as a Service”)• Your gear, your systems management/controls, their space

• Infrastructure as a Service (IaaS)• Their gear (dedicated to you), either theirs or yours in terms of

systems management/controls, their space

• Software as a Service (SaaS)• Their gear, their software, their space (they deliver, you consume)

• Disaster Recovery as a Service (DRaaS)• Some flavor of the options above

• Platform as a Service (PaaS)• Their gear (shared among many), a MIX of theirs and yours in

terms of systems management/controls, their space

We can’t simply be “Captain NO”

Understand the value proposition• Cost Reduction

• Pay on demand only for those services required by business need• Reduce capital expenses

• Cost Control• Operationalize or capitalize expenses in a more rational manner• Stop paying for exorbitantly expensive hardware and the associated

depreciation and renewal cycles

• Scalability• Spin up, spin down services in conjunction with processing demand• Replicate environments only as needed

• Recoverability• Create business continuity relatively easily

• Cool Factor• Some executives want to seen as being on the bleeding edge

How can you help?• ASK:

• Can we afford to entrust an external organization to manage/store a particular class of data?

• What contractual protections are in place in the event of a breach?• What is their control posture and what certifications can they offer

to corroborate this independently?• Terms and conditions of the contract

• Length of term and auto-renewal

• Service Level Agreements that the hosting provider will meet within the quoted pricing

• Support needs and availability • Depreciation and capital investment versus outsourcing costs:

What is the true TCO?

Avoid “Security Theater”

Setting the stage• What was this migration all about?• Small company acquired in mid-2013, based in the UK• Purchased from a large recruiting company that wanted to

divest itself from the job board business • Our leadership wanted to move to the cloud for several

reasons:• An earlier acquisition was already using AWS in what was

perceived at the time as a more cost effective manner• Begin to limit dependency on hosting in the Central US• The infrastructure and network capabilities of a PaaS vendor would

allow for faster global user delivery• The Cool Factor

Who we selected• Settled on Amazon Web Services

• Virtual Private Cloud (VPC) within their Elastic Cloud Computing (EC2) environment

• Why?• Cheaper than some of the other service providers that we looked at• Same provider that was in use at the time for another DHI property

(some existing degree of internal expertise)• Most mature service provider in the PaaS space• Existing global infrastructure that most met our specific

requirements

FINALLY: Let’s talk controls!• Let’s start talking about controls • This runs the full range of controls across the INFOSEC

spectrum• Network level• Host level• Physical security considerations• Authentication & authorization• Monitoring• Vuln/Pen testing• Operational/policy concerns

• But first, it’s critical to understand the concept of the hypervisor and its role in a PaaS implementation

Understand the PaaS Hypervisor Model

Start at the basics: Physical Security• Standard concerns, but in a non-standard manner:

• Site access control• Rack access• Background checks of trusted “employees”• CCTV/Physical access systems• Perimeter creation & enforcement• Lighting & environmental construction• Power distribution & backup capabilities• Susceptibility to catastrophic threats versus compensating controls

• “Non-standard” because you likely won’t be given specific details

• Leverage reliable auditing output versus relying on site visits • Acclimate yourself with a good outsource vendor’s control and

site configuration

Anti-Malware• Vendor selection at the host level should be at your

discretion, not the provider’s• Don’t overlook the potential for using an open source

provider• Understand the licensing and cost implications with a

subscription provider should you constantly spin up and down environments: Costs could increase exponentially!

• Ensure that you cover production and “production-like” instances equally

• Don’t forget the need to apply all host level controls to development and QA environments to replicate the production environment

Access Control• You’ll be provided the ability to establish access control

natively within the provider’s access structure• Understand the implications of how you build this; access

control at the provider level is your primary discretionary control!

• As always, strictly limit administrative access • Layer in additional host level controls locally as needed

• LDAP • Bastion hosts• SSH

Remote Administrative Access• lockdown, LockdowN, LOCKDOWN!• Clearly understand what options are available to you as

the customer to control remote access before any contracts are signed

• Create PPTP by restricting administrative access to select source IP addresses on your network

• Encrypt via SSH • Utilize a multifactor authentication solution

• Use whatever the provider offers natively• Layer in your own additional control (e.g. Duo Security, Google

Authenticator, etc.)• Ensure that your provider at least offers something to establish

MFA

Network Firewalls• In a PaaS implementation, you will have no authority to

manage ACLs or routing configurations • Analogous to the physical security configuration of a

serviced office model • In-line NIPS/NIDS are not an individualized option, either

• Validate that the provider has these controls in place • Understand that these controls are intended to protect their shared

infrastructure, not just yours • May not be as quick to deny traffic with signatures of an SQLI,

CSRF, or similarly nefarious attack pattern as you would be on your own network

Local Firewall• Should be fully at your discretion to install a firewall at the

local level; validate with the provider before signing• Remains under your control and configuration• As with any installation, close ports that aren’t used

explicitly by the application that’s hosted• Consider strongly the possibility of limiting port

accessibility to specific IP addresses or hosts if possible• The market hasn’t quite caught up with this yet

• Similar to the MDM/BYOD space five years ago where functionality outpaced the availability of controls

• Very fluid with new vendors entering the market regularly to fill the void; stay tuned and stay educated

Additional Network Controls• Standard NAT structuring available• Standard routing tables and capabilities exist within and

between hosted builds in your instance• Your ability to restrict access at the network level should

be identical to that of your internal, on premise network• Validate the extent to which the statements above are true

with your selected provider; No surprises after the fact!

Local Host Controls• Layer in HIPS/HIDS to the extent possible, but bear in

mind the dearth of products that can provide HIPS at the moment (seem to be primarily HIDS based)

• Deploy file or process level controls/lockdowns and limitations to the extent that your budget and technology SMEs can support it

System Architecture & Design• You can and should architect your cloud deployment just

as you would an internal build• A classic DMZ/App/Database layer design is possible,

with any variation in between• But, be aware that virtual instances are licensed on a per-

build basis in a cloud deployment, so you’ll likely be pressured to approve some creative design in the interests of cost containment

• Be flexible, but only to a point

Logging• Ensure that you have local host logging to the appropriate

level • Centralize and encrypt web/app/data logs to the extent

that you can do so in a centralized location• You obviously can’t insert your own log management appliance in a

PaaS implementation, but many vendors offer virtualized instances specifically for these deployments

• Ensure that collection agents are included as a part of the automated build for virtual instances that spin up and spin down on demand• Production is obvious; less obvious environments like DR and QA

should be considered as well given that they likely include loads of production data and are a prime target for any attacker

Instrumentation/Alerting• Treat your cloud deployment as you would an internal

infrastructure build out; deploy the same instrumentation around CPU performance, system availability, etc.

• Build alerting in just as you would for any critical system that you host internally; there should be no differentiation

• Your ability to page out system alerts through SMTP, SMS, etc., should be considered holy and platform agnostic

• Reminder: Don’t forget about mapping where instrumentation and alerting should live from an environmental standpoint; applying “it” to all environments may be cost prohibitive

SIEM• You should be able to bring in your own virtualized

instance of your chosen SIEM solution• Assumes that your SIEM provider has a virtualized product

available for a cloud implementation• ASK EARLY! You don’t want to be surprised late in the game by

learning that your SIEM product cannot be extended to a cloud solution

• Ensure that connectivity to your outside alerting mechanism or service is built into the cloud deployment by your network and system engineers. Traffic could be blocked otherwise

Controls Intermission • Let’s take a quick break for a relevant (and painful) story• The moral: Anticipate and articulate the time constraints of

building an adequate control environment to the business and technology stakeholders when schedule scoping is underway

Testing: Manual Vuln/Pen Tests• Validate with your provider what limits they’ll impose on

your ability to conduct testing; there will be limits!• Start the approval process as early on in the build out as

possible• Don’t limit yourself to black box testing only; a cloud

deployment does come with a higher degree of risk, so provide your testers with credentials to the extent possible to incorporate white box testing as well

• DoS or DDoS testing may very well be restricted by your provider per contractual limitations; understand that this is an area where you leverage the shared purchasing power of a cloud arrangement

Testing: External Vuln/App Tests• Permissible and expected by major PaaS providers• Approval process remains a requirement• Expect to have to provide them with the testing vendor’s

name and any originating test source IP addresses• Providers are hesitant to provide testing exceptions with

an expiration date where the ACL exceptions automatically expire. • Don’t be surprised if you have to provide them exception

paperwork on a recurring basis (monthly, quarterly, etc.)• Build in a process to remind you of the need to submit this

paperwork when it’s required, or your tests will start to fail

Testing: Automated Internal Vuln Tests

• Again, permissible and expected by major providers• Work with your current testing provider to determine

whether they offer a virtualized testing instance• Remain flexible to the fact that you may have to consider

alternative vendors, either because of a lack of virtualized availability by your chosen provider, or to take advantage of agreements between your PaaS provider and an outside, preferred testing vendor• Ensure that you ask for sample testing output before agreeing to

migrate vendors so that you know whether their level of testing and findings presentation is to your level of satisfaction

SOC Monitoring• If you’re fortunate to have your own internal SOC, ensure

that they’re aware of the implications of this cloud deployment on their incident response and routing procedures

• This holds true for any external SOC monitoring solution that you may use for your internal infrastructure today• Validate with them that they have a methodology for collecting

alerts from your gear in a cloud deployment• Even leading vendors have been too slow to react to creating

virtualized log collectors within systems that have traditionally been appliances sitting in a proprietary or colo data center

Operational/Policy Controls• Treat your cloud deployment just as you do your internally

hosted infrastructure in terms of operational and policy controls• Change management• Incident management• Segregation of duties **• Release management• Standard build configurations• Use of file/disk encryption • So on and so on and so on

Metrics• Account for your PaaS implementation in metric reporting

just as you would for an internal deployment • Your goal should be to report operational INFOSEC

metrics for a cloud deployment as thoroughly as you do on your internal infrastructure; the hosting environment should be transparent

Some Uniquely Cloud Considerations• Cloud vendors may not have the same authorization

controls for the creation of new instances under your corporate entity; how will you limit rogue instances?

• Environmental or build instantiation is a significant cost risk• Determine early on what the approval process will be for the creation

of new builds or whole environments• Will new builds appear or disappear on demand and automatically as

volume and processing requirements spin up and down?• Will there be a manual approval process to keep costs under control?

• SPOFs remain a significant risk in something so new; ensure that knowledge transfer is a built in requirement

• Articulate cost of response immediacy in SLAs

Business Continuity Considerations• A major selling point of a PaaS solution is the ability to

replicate environments for BC/DR• Clearly understand how that structure works with your

specific provider; not all vendors offer the same capabilities• Be cautious of how you design your BC capabilities; an

“Availability Zone” may mean nothing more than a separate building on the same physical campus

• It may be cost justified to replicate your production instance to a separate facility in a separate region entirely

• Remember that this is the hosting component only; that does not constitute business continuity et al. Concerns such as plan document creation, recovery prioritization, RTO/RPO, alternative worksites for staff, etc., remain essential elements

Thank You!

Questions