Cloudwatching - Hewlett Packard Enterpriseh41382. · PaaS - Platform as a Service (HP Helion, Force.com, Azure, Zoho, Google Docs etc) ... • Restart connector – feed resumes

© Copyright 2014 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

Cloudwatching Damian Skeeles, Strategic Architect @securidee #HPProtect

© Copyright 2014 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. 3

Show of hands

Do you use the cloud? • Public Cloud? (Dropbox, iCloud, Instagram, etc) • Private Cloud (Current or upcoming project?)

How do you use the cloud? • SaaS - Software as a Service (Salesforce.com, etc) • PaaS - Platform as a Service (HP Helion, Force.com, Azure, Zoho, Google Docs etc) • IaaS - Infrastructure as a Service (HP Helion, Amazon Web Service, Rackspace, etc)


The SIEM challenge

Infrastructure-as-a-Service

When thinking about IaaS • How do you incorporate your IaaS cloud into your existing SIEM monitoring? • How do you scale your event collection as flexibly as your cloud servers? • How do you ensure no log goes uncollected?


Agenda Cloud clarification Cloud challenges Connector strategies Methodologies tested

• Baked-in Connectors via SyslogNG • Fully auto-deployed connectors

• Alternative approaches • Conclusions • Questions


Cloud clarification


Where did all the puns go?


Other HP security solutions in the cloud

Compliance stack

Cloud connections

Fortify On Demand

Your IaaS

User auth. User activity

HP ArcSight

HP ArcSight

HP Fortify HP TippingPoint

HP Atalla

DVLabs


Infrastructure-as-a-Service

PaaS

IaaS

SaaS

Application

User

Application

Information

O/S

Network

Physical

O/S image

Information

Application


Cloud challenges


Cloud challenges

Cloudbursting • Can launch instances at any time • Collection must be partially/fully

automated • SIEM registration • Device connection • Collection Initiation • Inclusion in existing controls/models • “Zero-touch”

• Monitor the monitor (health) • De-provisioning

Collecting in the cloud


Connectors in the cloud

• Software • Can deploy as agents • Can collect remotely • Multiple types per install • Normalisation to suit source • Impose/infer modelling • Encryption • Filtering and compression ($) • Daisy-chaining • Remotely managed • Free

Benefits $0


Connector strategies

How can we deploy connectors? 3 architectural approaches 2 deployment methodologies


Cloud strategies/architecture

Nice and easy • Syslog / Rsyslog / SyslogNG where available • Snare for Windows • Hard-code Connector Address (or use DNS/script)

Advantages • Simple, lightweight

Disadvantages • UDP514 Insecure / Unreliable • Certificate exchange? for secure • Not supported by some products

1. Remote listening – “just use syslog”



More involved • Find means to install connector on each server

Advantages • Supports most / multi products as agent • Assure inclusion of new instances in monitoring

Disadvantages • Large footprint on server • Provisioning / Deprovisioning to ESM? • Connection limits on ESM?

2. Per-server agents talking directly to manager



Complex, but more robust • Agent(s) deployed on each server • Secure, reliable SyslogNG TLS to Relay • Relay forwards events to ESM

Advantages • Secure and reliable end-to-end • No need for de/provisioning Connectors on ESM

Disadvantages • Certificate management from Agents to Relay • Relay-link issues (management, field modification)

3. Per-server agents talking via relay connector


Cloud strategies/deployment The steps needed to set up a connector

Service start

Additional connector types

Service installation

Registration to destination / certificate

Device collection configuration

Installation directory

Connector installer


Service start



Registration to destination/certificate



Connector installer

Cloud strategies/deployment

Method • Install connector, service, configure, and register • Save image with connector configured

Advantages • Easy to prepare and test – assured function

Disadvantages • Any modification requires entire image re-build • Scripts to re-register to destination / restart

A. Steps for ‘baked-in’ connector


Cloud strategies/deployment

Method • Create silent installer file from vanilla instance • Auto-install from new using scripts/answer files

Advantages • Registration / Service installation part of service • Can host installers / scripts / configs off-image • Tweak startup configs without changing image

Disadvantages • Very easy to get wrong – hence fail on start • Cleartext passwords in silent answer file

B. Steps for auto-deployed connector

Service start



Registration to destination/certificate



Connector installer


Methodologies tested

How do we do this, and how well do they work?


Test methodologies

A. Connectors baked-into images, sending SyslogNG TLS

Installers & scripts

Baked with connector

B. Image to download, install, configure, run connectors via user launch command

Vanilla image

Launch-time Command


Test architecture

ESM 10.0.0.11

AD DC / Relay / Fileserver / RDP

10.0.0.13/4

Subnet 10.0.0.0/24

Internet Gateway: IGW

VPC: (10.0.0.0/16)

Windows Prototyper 10.0.0.204

Launched image Launched image


Launched image

Subnet 10.0.1.0/24 Subnet 10.0.2.0/24

AD DC / Relay / Fileserver

10.0.1.13/4


Launched image

Network Access Control



A/3: Baked-In Connectors via SyslogNG


Baked-in connectors via SyslogNG

SyslogNG relay • Install as Type SyslogNG • Select TLS Protocol • Install as service / finish / exit

Windows end-point connector • Install as normal • Register to Relay

Set up relay and end-point connectors



End-point connector • Should detect client is SyslogNG connector • Auto-pull relay’s certificate into keystore

If auto-registration fails • Copy cert on Relay at .\user\agent\syslog-ng.cert

onto end-point connector • Import into endpoint connector’s keystore using keytool —import —alias agent —file syslog—ng.cert —keystore . .\lib\security\cacerts

• This imports SyslogNG relay cert into end connector and establishes trust

Register to relay - configure certificates


Baked-in connectors via SyslogNG Prototyping system

ESM 10.0.0.11

AD DC / Relay / Fileserver

10.0.0.13/4

Subnet 10.0.0.0/24

Prototyper 10.0.0.204

Windows

SyslogNG



Generate baked-in image • Stop end-point server • Generate AMI

Make image


Launching the environment (video)



Launching the environment (video)




Custom ESM dashboard • Existing ESM connector content may not work

• No direct connection / connector registration • Original agent Issue • Device Monitoring issue

• Build custom DMs built on device fields • View relay device end agent device

Check foundation content works • Eg. test_user failed login 5 times – works fine

Check feed from launched instances



Custom ESM dashboard • Shut down relay connector • End-point connectors DO cache • Restart connector – feed resumes

Is the transport reliable?


Observations


Overview • It works! Launched instances just appear • Generally works with Foundation content

Cautions • Old events from Prototype system may re-appear for each launched instance

• Win hostname was resolved as prototype? • Avoid start_at_end = true, or cleanse logs

• Possible forwarding speed limitations • SyslogNG currently replaces Original Agent fields • Multiple connector config not on Win2008 GUI



B/2. Auto-deploy to Register Directly to ESM


Auto-deploy to register directly to ESM

Method • Launch vanilla server

• Parameter in Launch command to download/execute script

• Auto-download installers, scripts, configs • Prepare System • Scripts run silent installer

• Install binaries • Register to Manager • Install Service

• Start service • Remove installers after install

Overview

Installers & scripts

Vanilla image

Launch-time Command



• Service pre-installed on Basic AMIs • Generally to feed user data (eg. Config mode) to AMI

on launch • Can execute Batch or Powershell script

• <script>call c:\startup.bat</script> • <powershell>

$wc = New-Object System.Net.WebClient $wc.DownloadFile("http://myinstalls.s3.amazon.com", "C:\Connector_self-installer_v1.exe"); & 'C:\Connector_self-installer_v1‘ </powershell>

• Only runs on launch – re-enable for testing

Ideal situation • Powershell download ZIP from S3, unzip and run

Slight cheat • Execute batch file from c:\startup using User data

Using AWS EC2CONFIG



• Create Connector user/Event collector user • Confirm file share access to installer files • Place startup script

Slight cheat: Prepare server


Auto-deploy to register directly to ESM Script sequence

User Data in AWS

Command startup.bat cloud_install.bat

Connector Installer – Silent file

• Download Script

• Launch Startup Script

• Copy all installers from share

• Check paths • Append to

.\hosts • Insert hostname

as agent name in silent.properties

• Run silent installer

• Install binaries • Configure connector • Install service

• Start service



1. User data launch • Accepts EC2 CLI, Text, or File

2. Startup.bat

Script sequence



3. cloud_install.bat • Check paths

• Insert hostname as agent name in

silent.properties (Find And Replace Tool) • Append to .\hosts • Run silent installer • Start service

Script sequence



Play-through install on prototyping system runagentsetup.bat –i recorderui • Writes file at end of config process • Careful of location/filename/privileges C:\silent.properties

Silent installer preparation



4. Call silent installer • [ Two parts to check before calling ]

• File and Installer Path • Connector name/Location

• Install binaries • Configure connector • Install service

Script sequence



Launch 5 instances of the vanilla AMI • Launch ‘vanilla’ AMI • Enter user data It works! • Connectors appear in UI • Standard connector dashboards

light up • Takes around 3-5 minutes for all 5

Does it work?



Overall • It works in principle • Neat installation process

Cautions • Silent install often failed – unsure why

• Symptoms similar to if answer file did not exist • Race condition? Check dependancies

• ‘Blackout period’ before connector is ready and transmitting

Observations


Alternative approaches



“Just use Syslog” • If you do elsewhere, then why not here?

Log shipping • Script transfer to Log Server • Pass responsibility to application owner • Need to handle non-standard collection method

Remote connector with scripted scanning • Update properties file with log sources from script • Eg. Windows Host Browser • Requires custom scripting

What else could we try?



3rd-party product • Eg., Trend Deep Security

• Installs using User Data field as before • Full HIPS with centralised Logging • CEF into ESM from central console

What else could we try?


Conclusions


Conclusions

Baked-in via SyslogNG • Include in Server Build process • No connector micromanagement • Build content to monitor monitoring

Auto-installer, via SyslogNG • More flexible • Perhaps better for minor image

variations (same logging config; different images)

Which would I use?


Conclusions

• Multiple device types per connector • Testing of asset modelling

• Auto-include into Asset model based on zone OR vulnerability scan

• Scripted VA scan on new device discovery

• Provisioning via GPO • AWS infrastructure (cloudtrail) logs • HP cloud provisioning /

AWS cloudformation testing

Further work


For more information

Attend these sessions

• Too late! This is the last slot. But check the replay when it’s released for:

• TT3089 Box Cloud Connector

Visit these demos

• Any – you have 10 minutes left.

After the event

• Contact me Damian Skeeles [email protected]

• Presentations will be posted after Protect at https://protect724.hp.com/community/events/protect-conference

Your feedback is important to us. Please take a few minutes to complete the session survey.

https://protect724.hp.com/community/events/protect-conference





Questions?


Please fill out a survey. Hand it to the door monitor on your way out.

Thank you for providing your feedback, which helps us enhance content for future events.

Session TB3046 Speaker Damian Skeeles

Please give me your feedback


Thank you

Documents

Cloudwatching - Hewlett Packard Enterpriseh41382. · PaaS - Platform as a Service (HP Helion, Force.com, Azure, Zoho, Google Docs etc) ... • Restart connector – feed resumes