Wednesday, May 8, 2013

CISSP webinar SDN

lenght: 01:00:00
presenter: Kevin Walsh

SDN  Software Defined Network


separated in 4 layers

motto: separate what we can & concentrate what we can.

SDN strategy that addresses the key challenges customers face with 4 steps approach:

1. centralized management
2. extract services
3. centralized controller
4. optimize the hardware


Step 1: Centralize Management:
Centralize network management, analytic and configuration functionality - a single master that configures all networking devices.
This lowers operating cost and allows customers to gain business insight from their networks.

Step 2: Extract Services:
Extract (networking and security) services from the underlying hardware.
This enables network and security services to independently scale using industry-standard x86 hardware based on the needs of the solution. This next generation of programmable networks will be introduced with the JunosV App Engine.

Step 3: Centralized controller:
The brain of SDN that enables multiple network and security services to connect in series across devices within the network.
"SDN Service Chaining" -- using software to virtually insert services into the flow of network traffic. Service chaining functionality is crudely accomplished in today's physical world using separate network and security devices. With SDN Service Chaining, networks can dynamically respond to the needs of the business. This step will dramatically reduce the time, cost and risk for customers to design, test and deliver new network and security services. Juniper Networks anticipates delivering SDN Service Chaining functionality in 2014 utilizing the SDN controller technology acquired from Contrail Systems, together with the evolution of the JunosV App Engine.

Step 4: Optimize the HW:
Allow the usage of network and security hardware to deliver high performance.
The combination of optimized hardware together with SDN Service Chaining allows customers to build the best possible networks.

6 principles:
1. Cleanly separate networking software into four layers (or planes) -- management, services, control and forwarding.

2. Centralize the appropriate aspects of the management, services and control software to simplify network design and lower operating costs.

3. Use the cloud for elastic scale and flexible deployment, enabling usage-based pricing to reduce time-to-service and correlate cost based on value.

4. Create a platform for network applications, services and integration into management systems, enabling new business solutions.

5. Standardize protocols for interoperable, heterogeneous support across vendors, providing choice and lowering cost.

6. Broadly apply SDN principles to all networking and network services including security from the data center and enterprise campus to the mobile and wireline networks used by service providers.


traditional network challenge:
multiple copies of config
cant easily scale
time consuming & prone to error
maintain true network config

Benefit of SDN:
centralized config
extensive automaticion - scale with ease
point&click
centralized manager of true network config


data center:
server is virtualized
storage is virtualized
network is not yet virtualized

Labels: , ,

Tuesday, May 7, 2013

webinar - SDN Overview

length: 01:00:00

Mohammad Al Khalidi, Juniper ASCE

SDN is a concept by which the data and control plane are decoupled on a network level. The control plane functions are carried by a network controller, which controls the whole network devices. Hence, by programming the  centralized controller, you "program" the network behavior.

The idea came from application developers that would like to slice out a part of the network for testing new ideas and protocols, where any new protocol can be designed/tested and implemented on a life network, without affecting the network operations.


application layer: serves
control layer: controller
network layer: switches
host/data layer: clients


2 elements of SDN:
1. network controller
2. network switches.

a vendor can develop only network controller or only network switches or develop both controller & switches.


Main difference:
1. no protocol run between the network devices
2. when network switch receive packet for the first time, it buffers and consult the controller by sending the packet header
3. controller check the header, and based on the info, decides which rule to put & how to forward traffic
4. controller opens path for the data stream across the network


Advantages:
1. better network utilization & faster convergence
2. controller has more processing power
3. faster feature deployment
4. no need of routing protocol
5. mobility of the devices

Disadvantages:
1. latency
2. redundancy of controller - single point of failure(?)
3. complexity of controller


Openflow is the protocol that runs between the controller and the network devices. It is currently maintained by the Open Network Foundation.

Makes use of flow tables inside routers and switches, and allows the controller to manipulate these tables based on the network requirements.

Need of standardized protocol & vendor interoperability

Based on a match condition on the variables in the packet header (up to layer 4) -> filter based forwarding.

Openflow is not necessary the only protocol for controller/device communication for SDN networks. It is practically the only protocol being discussed in this field.

Current version: 1.3

Google is pretty happy with the SDN experiment, question arise such how the

SDN in practice:

wifi mobility was one of the first application was developed with the concept of SDN.


Load balancing:


benefit, controller knows where the clients and where the serves - hence it allows optimization of the traffic.
it really can optimize & make the best use of the links.



3. Application Driven Network.
the application can drive the controller decisions - it allow the servers to talk to controller and in turn the controller redirect the traffic
very mature: having the application to talk to the network.




Conclusion:

SDN started as concept to run testing programmable network along side the traditional network
SDN proved to be very appealing in many application - demands is up
interoperability between all vendor, cost reduction,

Labels: , ,

Thursday, February 21, 2013

CISSP CPE - Patching your employee's brain

length: 01:00:00

Presenter: Pieter Danhieux




Labels: ,

CISSP CPE - Introduction to Android Malware

length 01:00:00

presenter: Daan Raman - NVISIO


















note: McAfee has blog about this:
http://blogs.mcafee.com/mcafee-labs/android-malware-pairs-man-in-the-middle-with-remote-controlled-banking-trojan
















Labels: ,

Tuesday, February 19, 2013

CISSP CPE - Incident-Response, Malware Analysis, Digital Forensics

Length: 01:00:00

Incident-Response, Malware Analysis, Digital Forensics

Presenter: Steve Armstrong

Security Incident in Rasperry Pi.

Paterva / Maltego

Event Viewer -> MS -> Terminal Server

Incindent:

MGT:
-    Risk
-    Impact
-    Progress
-    Time left

DFIR:
-    Progress

Dradis – for pen-test
Trello/SaaS

Exec: Mission mode / Saas


Cyber CPR: Crisis Planning Plan Room

PHP base

Test/light/asset/API/Mantego Tranform

Workflow.
Cockoo – malware analysis
Snort – pcap analysis
Tintan – IP intelligence analysis
CIF – Community analysis

Labels: ,

Monday, February 18, 2013

CISSP CPE Cloud Security


length: 01:00:00

Presenter: Dave Shackleford

1. It is outsourcing, really
- someone else has your stuff
- someone else can cause harm

2. virtualization security is critical
2008-20120: vulnerabilities doubled
2011-2013: nasty vulnerabilities

Amazon: Zen
VM lost some code last year (3 days ago)

Virtual machine escape – guess
VMtool binary planting


3. Pay attention to human side
OS /Virt/Net/system Admin
No control
Priviledge uses Monitoring (CPU monitoring)
CSP process
Termination procedure
Security clearance

4. Not all Close are created equal

Amazon AWS: pen-test, IAM, FW (stateless), multi factor authentication
MZ Azure: little no network security, detailed SDLC program

Host close security 
Rackspace vs terremark


5. Standard?

Zero standard  - no format standard
CSA: Cloud Security Alliance
ODCA Open Data Center Alliance
Fed RAMP
ENISA
No “time” compliance standard

6 Interoperability  = Nightmare
Standard does not always means interoperability
Identity and Access Management
SAML or Not
VM format?
FW rule
Most CSP application
SDLS – SaaS / PaaS
API – notoriously insecure

7 Do not Fear the unknown

Scary cloud
What is in there
Question: CSA Consensus Assessment Initiatives
 CSA Cloud Control Matrix

SSAE IG SOC, SOC2, SOC3
How to audit? Mostly don’t allow
CTP Cloud Trust Protocol

8. Liability & Risk Transfer

This is impossible
Contract are important than ever
SLA do not begin to cover holes for:
-          Location of data representation
-          Verification & cross provision
-          Choice of law & venue
-          Ability to change term
-          Dispute resolution procedure
-           
9 Data understanding is the key

How long data is retained?  
Data import/export
Data format
Data location
Data persistence
Case for law enforcement
Encrypted?

10. You cant have it your way

Most large cloud provider will not make exception: security

Need to examine the company/service


Security does not control your operate
Business does not control your operate


--
Last note: if you think you don’t do cloud – you do cloud!!!

Google standard contract: if we have data bearch max reimbursement 10’000 $

TO DO: read the contract c a r e f u l l y



Conclusion:

Good news: new option

Cloud Passage:
Akamai
zScaler
okta


Questions:
1.       Can I trust the provider?
2.       How can I use the cloud?
3.       What are its unique capabilities?

Step1:
Determine the needs Why?
Determine type of provider?

Step2:
Determine the Security needs?
No DLP?

Step 3:
Investigate the provider(s)



Don’t fear the cloud
There are very good clouds out there
Live vite
Legal
Data interception.

Labels: ,

Tuesday, October 23, 2012

CISSP DLP - The missing part in IT security

length: 01:45:00
webinar with Joerg Buckbesch, Juniper ASCE.




DLP - The missing part in IT security

physical things : entering (access control) - leaving (locks, alarm, localization)

data/code: entering (FW, IPS, AV) - leaving (DLP)


Up to today - many companies do not have DLP :(


Why it is needed?
* Protection equipment: secret, IP, personal data (law), customer's data.
* Cause of Risk: espionage, data theft, disgruntled employee, thoughtless action.


Why is DLP missing?

The past: network as simple & clearly define boundaries
Now: everything is connected & boundaries becomes blurred - Complexity.

What is DLP? Data Leakage Prevention

What is NOT DLP?
-pure encryption,
-focus end to end


What makes up DLP solution: 3 Cs
C: context and context awareness.
C: Coverage.
C: Centralized management.


Challenges?
1. Technology
2. Regulatory Compliance (mandatory - prohibited)
3. Implementation & Operation
4. Cost

DPL process is repetitive:
Assess >  Plan > Implement > Activate > Maintain

DLP tech:
storage (servers) - network (file transfer) - end device (storage media)

search - monitor - protect - administer


Functional area:
* Storage: desktop, database, fileserver, content management system, mail server, webserver..
Access to the data: R/W account for DLP
Scheduled scan
handling of encrypted data

Network: various protocol,
performance impact consideration
handling of data encryption
conditional blocking
Blocking Network traffic requires some kind of chasing -not possible for FTP, but works well for email.

End device:
DLP agent
Blocking of violation actions
Scanning of local storage: email, copy data, burn cd/dvd, print, copy & past new file.
Online-Offline operation



Data detection:

CDM: Content data matching
search for certain keywords
lexical / statistical analysis
regular expression
data label & format

Indexing of structured data
Indexing of unstructured data

Policies, incidents, response rule, report.


Operation flow:
* Storage:
config & activate
identify & find scan target
search for confidential/protected
..


Network:
config & activate
detect attempts to send confidential
react on transmission
report on the incident

End device:
install DLP endpoint agent
configure & activate DLP rules
detect send, copy, print
react on activities violating DLP rules
report on incident


Administration Role:
Project manager
system-admin
incident response team
policy management
steering group

Labels: , ,

Wednesday, August 15, 2012

CISSP CPE: webinar Evaluation next generation IPS

length: 01:00:00


Evaluation next generation IPS

Mattew Glenn, VP product management McAfee

Vikram Phatak, CEO, NSS Labs

Tyler Carter, Director product marketing McAfee


1. Product analysis: 10 vendors
2. Comparative Analysis Reports:
a. security
b. performance
c. management system
d. TCO (total cost of ownership

3. Security Value Map
Interesting so many vendors are top left corner.

In previous year, NSS show the default security effectiveness, but this confuses the CEO, resulting budget are not properly allocated.


Right Size not same throughput.

Concurrent connection and connection per seconds are important



Throughput and latency is also very important.




Security effectiveness: Desktop protection:



Overal security effectiveness:



McAfee has very good management platform.

McAfee power of GTI (Global Threat Intelligence):


Using threat reputation and SIEM to collate all the threats.


it has application awareness
it has contextual awareness
it has content awareness

NOTE: all screenshot taken during the webinar.

systemic approach to malware: detect & prevent

full analysis automation: detect, ID root cause, determine, prevent.


NSS will do 0-day test moving forward.


Audience Question
Q: can we get a copy of this very good presentation?
A: The recording will be made available.  We are not planning to send out the slides.



Audience Question
Q: How can we obtain/access the broadcast?
A: You will automatically be sent a link to the recording after the broadcast, via email.



Audience Question
Q: Within the testing process, and from you info,am I correct to assume the device are tested against a set of know/signatured set of exploits. If that is correct within the testing how is the ability to identified and protected against a anomily that is an important feature/function of a good Netwotk IPS...Your thoughts on is this testing showing the ability of each as far as anomily detection and reporting untila signature is available....
A: Thanks for the question. I'll queue this up for Q&A at the end.



Audience Question
Q: Can GTI integrate with other SIEM's than McAfee like ArcSight?
A: Thanks for the question.  I'll queue this up for Q&A.



Audience Question
Q: Is GTI a technology tied to the IPS or is this something separate?
A: GTI is built directly into McAfee Network Security Platform (our IPS), out of the box.  It's also included in most other McAfee security solutions. With our SIEM, it is available as a subscription.



Audience Question
Q: We currently have Intrushield is GTI available for this old product?
A: GTI is available with the M-Series line of sensors.  These were first released in 2008 and are the current model IPS for McAfee.  The original I-Series platform (released in 2003) does not have the newer GTI features for file and IP reputation.


My question:
Q: question for Vikram: it seems like this is the first time SonicWall & Palo Alto join the NSS test and doing pretty good, what your opinion in regards to the "new comers" compare to the "traditional" vendor such sourcefire & mcafee?
A: Some new interesting technology from new comers and quite impressive.
Vikram is cautiously optimistic.

Audience Question
Q: In order to benefit from the GTI, we need to provide the sensors access to the internet which for most of our customers
A: Correct.  For GTI, sensors need an internet connection to the GTI cloud.

Labels: , ,