SONAS Security Strategy

Ulf Troppens
3/8/2012 1:28 PM3/8/2012 1:28 PM
SONAS Security Strategy

Security
IBM CONFIDENTIAL
2011 IBM Corporation
Ulf Troppens SONAS Security Strategy
Agenda
1. What do we support today?

2. SONAS security roadmap discussion
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Fields of file security
Elementary security features
Compound security features
Security Hardening
Compliance to security standards like

IBM ITCS 104, DoD DIACAP, HIPPA
Authentication
Authorization
Multiple elementary security features

need to be aligned to enable one
compound security feature
Cloud / multi-tenancy
Encryption / Integrity
Auditing
Elementary and compound security features

must support ISV integration to provide
end-to-end solutions for vertical industries
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Elementary Security Features
Security Hardening
Apply best practices for secure configuration of Linux systems
Apply development and coding best practices for components developed by IBM
Apply test best practices for our own components as well as for whole SONAS product
Timely delivery of fixes (SONAS PTFs) to eliminate known security vulnerabilities
Authentication
Identify all internal and external users (SONAS administrator, SONAS NAS user, IBM service
personnel) and infrastructure components (backup server, replication peer) which access SONAS
Provide simple and reliable methods to verify the claimed identity of users and components
Easily integrate into customers already existing one or more authentication systems
Authorization
Grant or deny an already authenticated identity (e.g. SONAS user, SONAS admin, IBM service
personnel) access to resources (e.g. read a file stored on SONAS, execute a privileged command)
Protect data stored on SONAS, even if unauthorized persons get access to it
Detect unauthorized modification (tampering) of data
Auditing
Provide audit trail for all admin actions which change SONAS configuration
Provide audit trail for all access to files stored on SONAS
Provide audit trail for all security related events to detect internal and external attacks
4
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Compound Security Features

Compliance to security standards like IBM ITCS 104, DoD DIACAP, HIPPA
Security standards describe security policies to support business requirements of whole industries or
large individual customers
Customers: IBM ITCS 104, UGSv6
Industries: HIPPA, Common Criteria
There is many overlap among the different security standards
Security standards may require a specific configuration of many elementary security features
Formal certification typically requires an assessment by an authorized third party
Support for cloud and multi-tenancy
Cloud service provider must run multiple tenants on the same SONAS system
Multi-tenancy is a cross component topic, comprising elements such as:
Ability to provision storage and delegate management to a tenant or group
Allow quota management of each tenant
Metering
Security
Quality of service
Backup per tenant
Many elementary security features needs to be enhanced to support multi tenancy
The audit trail for file access of a tenant A must not be disclosed to a tenant B
A single SONAS system should integrate into the authentication infrastructure of multiple tenants
Files owned by a user of tenant A should not be exposed to files owned by a user of tenant B
General multi-tenancy architecture and roadmap is outside the scope of this presentation
Security roadmap must support multi-tenancy roadmap
ISV support
Many security features require integration into customers already existing ISV application
Example: Audit records generated by SONAS will be processed by external application for fraud
detection
5
3/8/2012 1:28 PM
IBM CONFIDENTIAL
SONAS Security Features

SONAS 1.0 / 1.1
SONAS 1.2
Umask 077 in system profiles
Further hardening of network settings
Disallow root logon via modem
Software currency (pickup security fixes)
SONAS 1.3
Banner message for admin access
Password policies to enforce strong
admin passwords
Session policies to prevent systematic
logon attacks
Security Hardening
Disable all Linux daemons not required

for SONAS
Linux firewalls (iptables) to block all
network traffic which is not required
Disallow ssh to interface nodes
Racks with lock-able doors
Hardening of network settings
(apply Linux best practices)
Restrict access to devices for admins
who are working on physical console
Authentication
AD with automatic id mapping

AD with id mapping in SFU
AD with id mapping in NIS
LDAP with id mapping in LDAP
NT4 / PDC with automatic ID mapping
No authentication with netgroup in NIS
AD with enhanced automatic id

mapping
Authorization
Use GPFS NFSv4 ACLs for access

control of all NAS protocols
Netgroups in NIS for AD authentication
Netgroups in NIS for no authentication
(support for NFS only)
Role based access control for admins
Secure LDAP for LDAP authentication

Kerberized CIFS and NFS for AD
authentication
Kerberized CIFS and NFS for LDAP
authentication
Auditing
External notification via SNMP

External notification via mail (SMTP)
Antivirus for CIFS
External notification via syslog

Audit trail for all CLI and GUI actions
which change SONAS configuration
Audit trail for logon, failed logon
attempts and log-off of SONAS admins
Multi-tenancy
Compliance
3/8/2012 1:28 PM
Improve compliance to IBM ITCS 104
IBM CONFIDENTIAL

Improve compliance to DIACAP
SONAS Security Features (2012 Roadmap)

SONAS 1.3.1
Security Hardening
SONAS 1.3.2
Disable unused NAS services
Upload config files and download dumps as
non root user
More password policies
Disallow anonymous CIFS user/group
lookup
Harden file permissions
Harden PAM configuration
Process for timely response to security

vulnerabilities
Regression test to find world-writeable files
Regression test with Nessus and ITCS 104
profile
Regression test with Retina and DIACAP
profile
Deactivate CTRL-ALT-DEL key sequence
Remove unused Linux accounts
SONAS 2.0
Disable interactive root ssh and root scp
over external network to SONAS
More password policies
More session policies
Harden SSH settings
Password to protect interactive sessions
of GRUB boot loader
Remove unneeded RPMs from ISO image
Local authentication
Authentication
Netgroups in NIS for AD/SFU authentication
Netgroups in NIS for LDAP authentication
Authorization
Audit trail for sudo actions
Auditing
Multi-tenancy
Compliance


Roadmap shows the current plan for 2012. Roadmap is

subject to change without prior notice. No commitment implied.
3/8/2012 1:28 PM
IBM CONFIDENTIAL
SONAS Security Features (GTS / Compute Cloud only)

SONAS 1.2
Security
Hardening
SONAS 1.3
Trusted access points

banner message for admin access
(standard feature of SONAS 1.3)
password policies to enforce strong admin passwords
session policies to prevent systematic long attacks
Disallow NAS access via HTTP

Disallow NAS access via HTTPS
Disallow NAS access via FTP
Disallow password based external root ssh to SONAS
Forward internal syslog to external syslog receiver

(no longer supported in SONAS 1.3)
Basic Linux audit logging for interface and storage
nodes
Audit file access to GPFS
Audit changes of system time
Eliminated need to customize internal syslog configuration for GTS

by auditing logon, failed logon and log-off of SONAS admin user and
external notification via syslog protocol
Changed audit architecture to support integrated management node and
auditing of storage nodes
Authentication
Authorization
Encryption /
Integrity
Auditing
Multi-tenancy
Compliance
Note: several security enhancements listed on the previous chart have been delivered on request by GTS
to support ITCS 104 compliance of public storage cloud (SCS) an compute cloud (SCE)
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Agenda
1. What do we support today?

2. SONAS security roadmap discussion
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Objective
Develop and maintain common understanding on current and potential future security
features of SONAS and related products
Consolidate all known customer requirements and align them to each other
Provide prioritization for the planning of future SONAS releases
10
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Case study: BAE

Huge Opportunity, multiple PB
Category Distributed NAS
Customer
App
Customer
App
Most security requirements fall into

Traditional NAS
Regional
Buffer
SONAS
Staging
Disk
SONAS
Regional
Buffer
CIFS clients
Lots of Security Needed, beyond DIACAP

Some permissions need 2 independent authentications
Release-able and a second query to ensure user can access the file
Need access to files with different permissions without copying it
Ability to authenticate and log of user reads
Store some encrypted data in the cloud
To meet these requirements, the NAS

system must provide
(1) the described security features
and
(2) integration in security products
which already exists in the customer
data center.
The customer can do all this with

NetApp and NetApp security ISVs
today. The customer pain point is
Consolidated NAS or Distributed
NAS, but their Traditional NAS
security requirements do not go
away.
Need audit-ability of any file access

logs of storage system access.
We cannot catch-up all these

requirements in one or two years.
Need more pragmatic approach
remote maintenance of storage cloud

file arrival notification in the cache
11
3/8/2012 1:28 PM
IBM CONFIDENTIAL
2) SONAS security
capabilities for traditional
NAS are behind competition
Elementary exposures
No auditing
No encryption
No ISV integration
And, and, and
1) Most SONAS
opportunities are
Shared NAS or
Distributed NAS
SONAS Security Gap
File
Maturity
Category
Example
Access
method
Access
Control
Other security characteristics
Isolated
(single tenant)
Traditional NAS
NetApp, N series,
V7000U
Files via LAN

(NFS, CIFS)
ACLs
Storage system protects storage container

and data. Sophisticated controls for
access to data beyond ACLs.
Consolidated
(multi tenant)
Shared NAS
NetApp vFiler,
Isilon, SONAS
Files via LAN

(NFS, CIFS)
ACLs,
partitioning
Same as above. Plus federated authentication (e.g. multiple AD and/or LDAP)
Cloud
(automated)
Distributed NAS /
Automated NAS
SONAS with ACE

(Panache)
Files via LAN

(NFS, CIFS)
ACLs,
partitioning
Same as above. Plus encryption of data

before sending to public storage cloud.
3) Shared NAS requires

partitioning with strong
isolation for secure sharing
of storage capacity.
4) Distributed NAS
requires sophisticated
encryption key
management to protect
data stored on cloud.
Today we see a lot of pressure for federated authentication (e.g. support multiple AD and/or LDAP) and
partitioning, but we will loose more and more opportunities due to lack of basic security features (Traditional NAS).
We need to invest in traditional security and federated authentication / partitioning to catch up with competition.
An investment in sophisticated encryption key management might be a competitive advantage. This investment
must include development of SONAS security features and ISV support.
12
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Taxonomy of Security Requirements
Objective
Method to group and prioritize the about 90 security requirements and suggestions
What do we do in the next 1-2 years and what not
Security enhancements for authentication, multi-tenancy and ACLs are driven by other teams
Category
Description
Prio
Elementary
security hardening
High impact to product serviceability

High likelihood of unauthorized access to data stored on SONAS / IFS
High risk for reputation of SONAS / IFS and IBM
Typically not explicitly requested by customers and not prioritized by brand
High
Further
security hardening
Good practice for enterprise product

Good for reputation of SONAS / IFS
Typically not explicitly requested by customers and not prioritized by brand
Medium
Minor security
enhancements
Minor effort
Requested by customer and prioritized by brand
High
Major security
enhancements
Major effort
Requested by customer and prioritized by brand
High
Further enhancements
All other requirements

Good for the product
May be requested by customers but not prioritized by brand
Not a security exposure
Not considered as near-term enhancement
Low
Do not loose sight of Elementary Exposures while catching up with major and minor customer requirements!
13
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Source: IBM Security Strategy

IBMs opportunity define a new approach to security adoption
In Sec
te u
lli rit
ge y
nc
e
iz
im
pt
Automated
O
ed
ic
of
Pr
nt
ie
c
si
Ba
Organizations
employ perimeter
protection, which
regulates access and
feeds manual reporting
Manual
Basic
Reactive
Optimized
Organizations use
predictive and
automated security
analytics to drive toward
security intelligence
Proficient
Proactive
Security is layered
into the IT fabric and
business operations
This approach of the IBM Security Strategy helps to prioritize within each category.
14
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Elementary Security Hardening (1/2)

Title
Description
Disable direct root access
It is a security best practice to disallow root logon on Unix-based appliances like SONAS. In addition, SONAS field support is out of control, because SONAS
and IFS customer can use root to issue native Linux commands to change SONAS / IFS configuration and scp to replace any files and executables on a
SONAS and IFS system. There is no audit trail of these actions.
Basic
Provide logging for all sudo tasks which are executed with root privilege (Committed for 1.3.2)
Provide non root scp to upload and download config and dump files (Committed for SONAS 1.3.2)
Disable interactive root ssh and interactive root scp over external network to SONAS (Committed for 2.0)
Disable all root ssh and root scp over external network to SONAS (Deferred due to dependency to async repl)
Disable direct root logon on physical attached console. Use sudo instead.
Disable password-less boot into single-user mode
Disable password-less start of interactive GRUB sessions (planned for 2.0)
Disallow boot from removable media
Proficient
Hardening of the sudo configuration
Disable all root ssh and root scp over SONAS internal networks
Enhanced Tamper Protection to allow only temporary root access for regular compliance
Linux hardening
There are a plenty of best practices for secure configuration of Linux like IBM ITCS 104 and DISA DIACAP.
Basic
Improve compliance to IBM ITCS 104 Linux TechSpec (ongoing effort)
Improve compliance to DISA DIACAP RedHat STIG (ongoing effort)
Systematic assessment for passwords and certificates used and stored in SONAS (must include log, trace and dump files)
Regular regression test to search for world-writeable files (Committed for 1.3.1)
Regular regression test with IBM lssecfixes
Regular regression test with IBM Tonic
Regular regression test with DISA SSR
Proficient
Integrity check (e.g. checksum) for all configuration files, scripts and executables
Hardening of the SONAS

software stack
Current SONAS hardening is focused on Linux hardening, because most current customers request compliance to security guidelines. Advancements such
as IFS, WSS and public storage cloud will deploy the SONAS software stack in less secure networks. A particular concern is the use of HTTP, REST and
CGI for SONAS WebGUI, SONAS NAS access, WSS and VAAI.
Basic
Improve compliance to IBM ITCS 104 Apache TechSpec
Improve compliance to DISA DIACAP Web Server STIG (detailed STIG to be determined)
Regular regression test with Rational AppScan
15
3/8/2012 1:28 PM
Proficient
Regular regression test with Rational AppScan source
Adopt Secure Engineering (SE) practices, IBM Secure Engineering Framework (SEF), and Secure Engineering in Test (SEiT)
(e.g. Location of temp files, coding guidelines) IBM CONFIDENTIAL
Elementary Security Hardening (2/2)

Title
Description
Timely delivery of fixes for

security vulnerabilities
The MITRE Corporation maintains a list of standardized names for vulnerabilities and security exposures, the Common Vulnerabilities and Exposures (CVE).
Customers demand that RHEL fixes for critical CVEs are available for SONAS in a timely manner, in particular more frequently than SONAS PTFs are
shipped. This becomes even more critical with WSS and cloud offerings which are connected to public networks.
Basic
SONAS process for dealing with RedHat Security Advisories and patches (Committed for SONAS 1.3.1)
Regular regression test with Nessus and IBM ITCS 104 profile (Committed for SONAS 1.3.1)
Regular regression test with Retina and DISA DIACAP profile (Committed for SONAS 1.3.1)
Proficient
SLA for timely delivery of security fixes (e.g., IBM ITCS 104 requires 3 days for high, 7 days for medium, 30 days for low for Internet systems)
Moving towards an appliance
Current SONAS is open like a default Linux server. Need to close several open doors to move towards a closed appliance.
Basic
Disable direct root access (see previous chart)
First time install and first time configuration without root access
Removal of unneeded RPMs
Restrict GNOME user GUI on physical attached console
Root logon for IBM service personnel only
Proficient
Disable unneeded ports of internal switches
16
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Major Security Enhancements

Title
Description
Audit logging
There is high market pressure to support auditing of security relevant events and configuration changes as well as audit of file access. This is in particular
required in markets with regulated workloads (e.g. health care, finance) and highly confidential data (e.g. US Government). Audit requirements include, but
are not limited too:
Audit of file access for all NAS protocols
Audit of file access via internal paths (e.g. by IBM service personnel)
Audit of mount actions
Audit of changes in system time
Audit of executed SONAS CLI commands which change system configuration
Audit of other security relevant actions
Forwarding of audit records to external ISVs (e.g. IBM QRadar, Varonis)
Tamper-proof storing of audit records inside SONAS
Audit internal logon, failed logon attempts and log-off events
Partitioning for few tenants
NAS consolidation must support storage provisioning to a small set of tenants whilst the data of each tenant must be strongly isolated to prevent
unauthorized of to other tenants data. See three AD + LDAP use cases of authentication chart deck for further details.
USGv6
In December 2009 the US Government issued a Federal Acquisition Regulation (FAR) that requires US Government procurements to be USGv6 compliant
17
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Other security requirements
18
Category
Description
Minor security
enhancements
Can be absorbed by current development and test team

Will be prioritized depending on customer need and business opportunity
Further enhancements
No market pressure
Right no need to deliver in the next 2-3 years
Check charts in backup section for a wealth of potential further security enhancements
Authentication
enhancements
Covered by Authentication team

Outside the scope of this analysis
Access Control Lists

(ACLs)
Covered by ACL team

Multi-tenancy
Covered by multi-tenancy team.

3/8/2012 1:28 PM
IBM CONFIDENTIAL
Recommendation
1. Do not loose sight of elementary security features while catching up with major and minor security
requirements
Have more attention on addressing elementary security exposures
Often perceived as additional burden by development, test, field support team
Needs strong management support to make it happen
Close basic level of elementary exposures by end of 2013
Security team has not the required component knowledge for hardening of some components
SONAS hardening is cross-component effort; needs committed resources beyond security team
Ramp up test resources for regular security regression test with a broad range of test tools
Establish task force to refine approach for hardening of SONAS software stack
Hardening of HTTP/REST/CGI requires skills which are rare (not available?) in current team
Need to build respective skill within SONAS development and test team
2. Develop strategy for ISV integration
What are the relevant (security) ISVs for instance of the health care industry?
What APIs are required to integrate with the identified ISVs?
What are the end-to-end use cases?
Creation of ISV ecosystem for industry verticals requires effort beyond security!
3. Market priority for major security enhancements seems to be:
1. Audit logging
2. Partitioning
3. USGv6
4. Concentrate near-term efforts (next 1-2 years) for major security enhancements on audit logging and
partitioning
Develop staged approach for audit logging
Provide a solution for partitioning with strong isolation for less then 10 tenants
Postpone support for USGv6
19
3/8/2012 1:28 PM
IBM CONFIDENTIAL
NEEDS MORE THOUGHT

Potential Roadmap
2012
2013
2014
2015
Improve closure of
basic elementary
security exposures
Closure of basic
elementary security
exposures
Improve closure of
proficient elementary
security exposures
Closure of proficient
elementary security
exposures
Audit logging
GA stage 1
GA stage 2
GA stage 3
Partitioning
TBD
(See authentication
roadmap in PARTIII)
TBD
(See authentication
roadmap in PARTIII)
TBD
(See authentication
roadmap in PARTIII)
2014 ?
Or 2015?
Elementary security
exposures
USGv6
2016
Pune security team needs support of other components to close all elementary security exposures.
Test team must be ramped up to enhance regression test for vulnerabilities.
Given the current security team size, roadmap for audit logging is on high risk.
20
3/8/2012 1:28 PM
IBM CONFIDENTIAL
BACKUP
21
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Contrasting Change
in Storage
Block
File
Object
22
Access method is the primary

discriminator of Block, File
and Object storage.
Maturity
Category
Example
Access
method
Access
Control
Other security characteristics
Isolated
(single tenant)
Traditional disk &

tape
SCSI disk,
SCSI tape drive
Direct
attached SCSI
Phyiscal
cabling

(e.g. tape cartridge, LUN). Server protects
data. Encryption.
Consolidated
(multi tenant)
Shared disk &

tape
DS8000, TS3500
Fibre Channel
SAN
FC zones,
LUN masking,
partitioning
Same as above. Plus some security

controls for storage admins.
Cloud
(automated)
Automated disk &

tape
TPC / TSAM
workflows
Fibre Channel
SAN
FC zones,
LUN masking,
partitioning
Same as above.
Isolated
(single tenant)
Traditional NAS
NetApp, N series,
V7000U
Files via LAN

(NFS, CIFS)
ACLs

and data. Sophisticated controls for access
to data beyond ACLs.
Consolidated
(multi tenant)
Shared NAS
NetApp vFiler,
Isilon, SONAS
Files via LAN

(NFS, CIFS)
ACLs,
partitioning
Same as above. Plus federated authentication (e.g. multiple AD and/or LDAP)
Cloud
(automated)
Distributed NAS /
Automated NAS
SONAS with ACE

(Panache)
Files via LAN

(NFS, CIFS)
ACLs,
partitioning
Same as above. Plus encryption of data

before sending to public storage cloud.
Consolidated
(multi tenant)
Local cloud
storage
SONAS with WSS
Object via
LAN (REST)
ACLs,
partitioning
Same as Shared NAS (?)
Cloud
(automated)
Traditional cloud
storage
Amazon S3
Object via
WAN (REST)
ACLs,
partitioning
Same as Distributed NAS (?)
3/8/2012 1:28 PM
IBM CONFIDENTIAL
NetApp Some security related ISVs
23
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Amazon Solutions
Is this caused by
block and file
storage is to difficult
to integrate and
IBM not having
object storage?
IBM pain point:

IBM Smart
Business Cloud
does not offer
storage.
Company
Customer value
add:
Amazon integrates
compute and
storage resources
ISVs
Comment
Object
Amazon
359
Includes EC2 and S3
File
NetApp
114
All NetApp
Block
IBM
12
All IBM Storage
Going up the chain, ISV

integration is critical for
market success.
https://aws.amazon.com/solution-providers
24
3/8/2012 1:28 PM
IBM CONFIDENTIAL

Security Intelligence: A Maturity Model Approach to Adoption

People
Data
Applications
Infrastructure
Data flow analytics
Secure application
development
Advanced network
monitoring /
forensics
Security
Intelligence
Optimized
Role based
analytics
Identity governance
Privileged user
controls
Proficient
SONAS
Basic
Identity
management
Strong
authentication
Passwords and
user identities
Data governance
Fraud detection
Access monitoring
Application firewall
Data loss
prevention
Source code
scanning
Encryption
Vulnerability
scanning
Access control
Secure systems
Asset management
Endpoint / network
security
management
Perimeter security
Anti-virus
Source: IBM Security Solutions Security Landscape and Technical Approach

https://fsccsvn.mainz.de.ibm.com/svn/fscc_internal/documents/design/Security/publications/IBM_Software_Security_Strategy.ppt
25
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Application Vulnerability Testing
Make Applications Secure, by Design

Security as an Intrinsic Property of the Development Process
Design Phase
Functional Spec
Consideration is given to security requirements of the application

Issues such as required controls and best practices are documented on
par with functional requirements
Development Phase
Manage,
Monitor
& Defend
Design
Software is checked during coding for:

Implementation error vulnerabilities
Compliance with security requirements
Build & Test Phase

Testing begins for errors and compliance with security requirements
across the entire application
Applications are also tested for exploitability in deployment scenario
Deploy
Develop
Deployment Phase
Configure infrastructure for application policies
Deploy applications into production
Outsourcing
Partner
Build & Test
Operational Phase
Continuously monitor applications for appropriate application usage,

vulnerabilities and defend against attacks
26
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Software
Application Vulnerability Testing
IBM Rational AppScan Suite

Comprehensive Application Vulnerability Management across SDLC
SECURITY
REQUIREMENTS
CODE
BUILD
QA
PRE-PROD
PRODUCTION
AppScan onDemand
AppScan Enterprise
Security
Requirements
Definition
Security
requirements
defined before
design &
implementation
AppScan Source
AppScan
Build
Build security
testing into the
IDE
Automate Security
/ Compliance
testing in the
Build Process
AppScan
Tester
AppScan
Standard
Security &
Security / compliance
Compliance
testing incorporated
Testing, oversight,
into testing &
control, policy,
remediation
audits
workflows
AppScan
Standard
Outsourced testing
for security audits &
production site
monitoring
Application Security Best Practices Secure Engineering Framework
27
3/8/2012 1:28 PM
Dynamic Analysis/Black box

Static Analysis/White box
IBM CONFIDENTIAL
Definition of 1.3.2 and 2.0 scope is still in

progress and therefore subject to change.
Retina Cat I & II

Retina
10
9
8
7
6
Cat I
Cat II
4
3
2
1
0
SONAS 1.2
SONAS 1.3
SONAS 1.3.1
SONAS 1.3.2
SONAS 2.0
Findings based on a Retina scan provided by the customer, run on Aug 2011 against SONAS 1.2 PTF 2
Need a new Retina scan to address vulnerabilities which have been reported after Aug 2011
Asked IBM Federal team but have not received an updated scan report so far
Planning to add Retina scans with DISA DIACAP profile to SONAS regression test
Remaining Retina Cat II findings need more details from the customer
IBM Federal team asked customer several times for details without receiving a response
Current position of the IBM Federal team is to reject the fix of these two findings
28
3/8/2012 1:28 PM
IBM CONFIDENTIAL

RedHat Cat I
RedHat Cat I
9
8
7
6
Total
Script
4
Exception
3
2
1
0
SONAS 1.2
SONAS 1.3
SONAS 1.3.1
SONAS 1.3.2
SONAS 2.0
Closure of remaining two RH Cat I findings is a medium effort

STIG V-4695 requires to disable TFTP, but SONAS install and upgrade depends on TFTP
STIG V-4382 requires root user not to run web browser, but field personnel uses web browser as root
All script based RedHat configuration changes which have been applied by the IBM Federal team on
SONAS 1.2 production systems will be incorporated in SONAS 2.0
29
3/8/2012 1:28 PM
IBM CONFIDENTIAL

RedHat Cat II
RedHat Cat II
140
120
100
80
Total
Script
Exception
60
40
20
0
SONAS 1.2
SONAS 1.3
SONAS 1.3.1
SONAS 1.3.2
SONAS 2.0
Closure of remaining RH Cat II findings is a major effort

Most of the low hanging fruits are already harvested
Some of the remaining are really big
=> E.g., full blown auditing accounts for seven of the remaining 69 RedHat Cat II findings
Recommendation on how to continue after SONAS 2.0
Continue to harvest the remaining low hanging fruits
Start to address the findings which are generic beyond DIACAP (e.g. auditing)
Get guidance from IBM Federal team, for which findings a long-term exception would be accepted by
the customer
30
3/8/2012 1:28 PM
IBM CONFIDENTIAL
Outdated. Page still contains good background

information, but needs to be scrubbed and updated.
Elementary Security Exposures

Prio
ID
Plan
597
red indicates that feature is not committed
Title
Description
1.3.2
stretch
Audit trail for all sudo

commands issued with root
privilege
SONAS field support is out of control, because SONAS and IFS customer can use root to issue native Linux commands to
change SONAS / IFS configuration. There is no audit trail of these actions. This LI provides audit trail of root actions by friendly
admins. Bad actions of attackers who bypass the sudo mechanism are not logged.
461a
1.3.2
Capability to upload config

files
SONAS field support is out of control, because SONAS and IFS customer can use root scp to replace any files and executable
on a SONAS or IFS system. There is no audit trail of these replacements.
533
1.3.1
Software currency for 1.3.1
Pick up RHEL 6.1 security patches, Postgres 9.1.1 fix pack and RHEL kernel 2.6.32-131.18.1.el6
623
1.3.1
SONAS process for dealing

with RedHat Security
Advisories and patches
The MITRE Corporation maintains a list of standardized names for vulnerabilities and security exposures, the Common
Vulnerabilities and Exposures (CVE). Customers demand that RHEL fixes for critical CVEs are available for SONAS in a timely
manner, in particular more frequently than SONAS PTFs are shipped.
624
1.3.1
Regular Nessus scan of all

supported SONAS versions
Nessus is an external scanning tool used by IBM with IBM profile to test Linux systems for known vulnerabilities. Running
Nessus regularly with an actual profile helps to finds exposures before customers find them.
430
Defer
Disable external root ssh
It is a general security best practice to disallow incoming root ssh. Disabling all external root SSH to SONAS has been deferred
because SONAS remote replication depends on ssh key based root ssh from source SONAS to target SONAS (see
requirement 479 for details). It was decided to disable external root ssh, once SONAS remote replication is fully replaced by
Panache.
613
1.3.1
1.3.2
1.3.3
2.0
No world write-able files
SONAS 1.3 produces a lot of internal files which are owned by root and are world-writeable and/or world-executable. SONAS
code must be changed to no longer create files with such permissions and the permissions of files on SONAS systems in the
field must be changed to no longer have such permissions. Requires staged delivery.
Note: Required to meet 581 DIACAP RHEL CAT I findings. Requesting 1.3.1 to support DIACAP.
DCR
74
1.3.2
Disable password based root

ssh to 1602
To reduce the risk of allowing external root ssh to SONAS, it was planned to disable all external password based root ssh in
SONAS 1.3, but this was deferred to reduce execution risk. Ssh key based root ssh will still be allowed to support SONAS
remote replication.
1.3.2
Pick up RHEL 6.1 security patches, details are TBD.
10
1.3.2
Protect all passwords stored

inside SONAS
SONAS stores many system passwords (e.g. LDAP, AD, TSM). All passwords stored on SONAS must be encrypted and files
which store passwords must have proper permissions. Passwords must not appear in clear text on CLI commands, GUI
panels, in log or trace files, in dump files, output of backup management node.
11
1.3.3
Disallow interactive root logon

over external ssh
To further reduce the risk of allowing external root ssh to SONAS for remote replication, all CLI commands and all ssh keys will
be removed which enable interactive root logon over an external network to SONAS. Ssh key based root ssh between two
SONAS systems for remote replication is still allowed.
12
1.3.3
Pick up RHEL 6.1 security patches, details are TBD.
13
1.3.3
audit trail for commands

issued by Enhanced / Service
user
We need an audit trail of all commands issued by Enhanced user / Service user to have a complete log of all configuration
changes applied to SONAS.
Ulf need to check with Steve Wallace if such a log exists.
31
3/8/2012 1:28 PM
IBM CONFIDENTIAL

Further Security Exposures

Prio
ID
622
618
32
Plan
Title
Description
2.0
CLI enhancements to
troubleshoot auth issues
Today we need root access to (1) to report group info, (2) Report user UID to name mappings for all user, (3) Report user UID
to SID mappings for all users, (4) check how that user get resolved, (5) check external auth server (e.g. like wbinfo for AD, (5)
detect/monitor issues with external auth server (e.g. LDAP not reachable)
2.0
Remove unneeded rpms
More and more customers assess SONAS to assure compliance to their security policies (= apply certain RHEL settings) and
to check that RHEL patches for known CVEs are installed. Removing unneeded rpms reduces development and test efforts for
software which is installed on SONAS but not needed.
2.0
Disallow all direct root login
Enforce that all commands with root privilege are executed via sudo. This ensures that bad minded admins can bypass audit
trail for root actions and thus completes LI 597 audit trail for all sudo commands issued with root privilege.
2.0
Regular AppScan scan for all

IBM Rational AppScan is a tool to test web application like SONAS GUI for known vulnerabilities. Running AppScan regularly
with an actual profile helps to finds exposures before customers find them.
2.0
Regular Tonic scan for all

Tonic is an IBM developed tool to test compliance of a Linux system to IBM ITCS 104. Running Tonic regularly with an actual
profile helps to finds exposures before customers find them.
2.0
Web server for SONAS GUI

must not run as root
An attacker who exploits a vulnerability of the http server will gain immediate root access to SONAS, when web server for GUI
is running with root privilege.
2.0
Web server for HTTP NAS

access must not run as root
root
An attacker who exploits a vulnerability of the http server will gain immediate root access to SONAS, when web server for
SONAS NAS access is running with root privilege.
2.0
root less first time

configuration
SONAS first time configuration requires root ssh to a SONAS system. So, when our customers touch SONAS the first time, we
teach them that using root is a good idea. We want to go away from customer and tester using root.
2.0
root less service of the

product
DIACAP:
It seems that Mozilla Firefox was started by root user on SONAS systems in the field (RH CAT I finding of JIEDDO program).
We need to revisit our service procedures to avoid or at least reduce the use of root for standard service tasks.
2.0
Implement PSIRT process for

proactive addressing of CVEs
and other exposures
Product Security Incident Response is a key element of the IBM Secure Engineering Framework (SEF). The IBM Product
Security Incident Response Team (PSIRT) is responsible for providing the right level of responsiveness in the handling and
reporting of security vulnerabilities that may affect IBM offerings. IBM defines a security vulnerability as a set of conditions in
the design, implementation, operation or management of a product or service that is unable to prevent an attack by a party
resulting in exploitations such as controlling or disrupting operation, compromising (i.e. deleting, altering or extracting) data or
assuming ungranted trust or identity. (https://d01db034.pok.ibm.com/q_dir/qmx/swg/qh0dl.nsf/procnum/PROCESS-0186)
2.0
SEiT: Location of temp files
When files are written to an open directory, this is a potential security hole as it is a common exploit. If a hacker gains access
to the directory and knows or can predict a filename that is written to this directory, they could potentially gain root access. The
test team scanned SONAS source code and found that writing directly to /tmp (rather than to a secure directory within /tmp) is
widespread.
3/8/2012 1:28 PM
IBM CONFIDENTIAL

Minor Security Enhancements (SONAS 2.0 or later)red indicates that feature is not committed
Prio
ID
Plan
Title
Description
489b
2.0
Trusted access point
GTS/Cloud:
Enhance SONAS CLI to restrict management access to SONAS CLI and SONAS GUI by accepting incoming connections from
trusted IP addresses only and blocking connection requests from untrusted IP addresses
616
2.0
Disallow boot from removable

media
DIACAP:
An attacker can tamper SONAS by booting an operating system from DVD and then manipulating SONAS configuration data
on disk. SONAS must be enhanced to disallow booting from all removable media and the capability to configure a BIOS
password. Current SONAS requires boot from DVD for first time install, not recovery and upgrade from SONAS 1.2 to 1.3.
596
2.0
Audit changes of system time
Multiple:
System time may be tampered to bypass retention period of immutable files
625
2.0
Audit internal logon, failed

logon attempts and log-off
events
Multiple:
Current white-list filtering does not catch internal logon / log-off events, because this would flood the SONAS event log.
SONAS management stack opens new ssh session for each command which needs to be executed on a SONAS node.
Access to Postgress DB triggers a lot of su events.
33
3/8/2012 1:28 PM
IBM CONFIDENTIAL

Major Security Enhancements
Prio
ID
Plan
Title
Description
299
1.3.2
Basic immutability
Initial support for immutable files
2.0
Audit of file access
HealthCare, GTS, multiple other: Capability to audit all file access via NAS protocols (e.g. NFS, CIFS) as well as direct access
to GPFS to support regular compliance and to detect unauthorized access to data stored on GPFS (e.g. bad admin action)
2.0
DIACAP CAT II RHEL HHF

(stage 1)
DoD: Address all DIACAP CAT II findings for RedHat configuration. Some of the findings are difficult to address. This LI
consolidates stage 1 of these high hanging fruits (HHF).
Future
DIACAP CAT II RHEL HHF

(stage 2)
DoD: Address all DIACAP CAT II findings for RedHat configuration. Some of the findings are difficult to address. This LI
consolidates stage 2 of these high hanging fruits (HHF).
295
Future
Password in AD and id
mapping in LDAP
Multiple: Capability to store passwords of SONAS NAS user in AD and their id mapping in LDAP. All available options have
major limitations and thus have been rejected by the DRT. Need to develop enabling technology to enhance Linux capabilities
for authentication configuration
495
Future
Support for multiple

complementary authentication
server
Multiple: SONAS shall support multiple exclusive authentication and id mapping domains. The SONAS storage capacity can be
divided in multiple partitions (e.g. GPFS file system, GPFS file set) and each partition can be associated with exactly one
different AD or LDAP server.
495
Future
Support for multiple mutual

exclusive authentication
server
Multiple: SONAS shall support multiple complimentary authentication and ID mapping domains. The SONAS storage capacity
will be associated with multiple different AD or LDAP server. SONAS will provide rules like: Look in AD No1 first. If no user
found, look in AD No2. If still not found, look in
143
343
Future
USGv6
US Gov: In December 2009 the US Government issued a Federal Acquisition Regulation (FAR) that requires US Government
procurements to be USGv6 compliant
600
Future
DIACAP CAT I App
DoD: Address all DIACAP CAT I findings for application development
Future
Encrypt data on cloud
Multi-tenancy / Cloud: One key inhibiting factor for adoption of public storage clouds is unauthorized access to customer
confidential data. We could enable ACE / Panache to encrypt data before it is sent to a SONAS based storage cloud. Multiple
customers could share data via cloud, by sharing the encryption keys. Integration into Tivoli Key Lifecycle Manager might be
plus.
Future
Integration into Tivoli Security

product line
Multiple: Tivoli offers a bunch of security products: TCIM, TSOM, TSPM, TAMOS, TSIEM. Tight integration of SONAS into
Tivoli product line could be a strong selling point for security sensitive customers.
Future
Basic Linux audit logging for

bad admin actions / events
This features is available for GTS / Cloud only. It would be good to have this for all customers.
Future
AD with SASL
AD with SALS is the preferred method to encrypt LDAP traffic between SONAS and AD. Some major non SONAS customers
are already using this.
Future
CIFS signing
Requested by Citi
Future
Authenticate SONAS admins

via LDAP
Requested by RedHat and Citi
34
3/8/2012 1:28 PM
IBM CONFIDENTIAL

Further requirements (GTS / Cloud)

Prio
ID
Plan
Title
Description
Future
Audit of mount actions for

NFS and CIFS
Future
Store audit logs inside

SONAS
9a
Future
Alert unexpected traffic
9b
Future
Alert manipulation of firewalls
13
Future
Eliminate reliance of TFTP
16
Future
Filter outgoing traffic
18
Future
Disallow root ssh over internal

networks
Current SONAS requires internal root ssh for GPFS and SONAS management stack
Future
Removal of use of root for

async replication
Secure (root-less) rsync-based remote replication + SysMan changes (CLI)
Future
Authentication of remote
replication endpoints
Utilize a proper industry standard based mechanism to authenticate endpoints of a data replication configuration.
Future
Data sanitization
Need more details to understand and prioritize requirement
Future
Additional technical controls

beyond mapping of persistent
storage in the TSAM xml files
around security
Future
SELinux support
402
Store audit records locally inside SONAS when external audit logging serve not reachable
This chart comprises security requirements identified by GTS which are not
integrated in the roadmap for 2012
The ranking of the priorities is listed as provided by GTS
35
3/8/2012 1:28 PM
IBM CONFIDENTIAL

Further requirements (other, 1 of 2)

Prio
ID
467
36
Plan
Title
Description
Future
WORM based logging
Prevent tampering of logs and audits records
Future
Use SELinux to prevent

unauthorized access to data
Provide additional control (e.g. SELinux) to prevent service personnel and root to touch data on GPFS. Access to data on
GPFS can be enabled via a new CLI command.
Future
End-to-end secure erase /

Data remanence
Future
End-to-end data integrity

(including T10-DIF)
Future
Two factor authentication for

SONAS admins
Future
Formal compliance
Future
Role based access control

(associated to objects, e.g.
gpfs1)
Future
Dual control of configuration

changes
Future
FDE/Encrypted Filesystem
Future
Policy-Driven File Encryption

Explorer Based On OpenPGP
for Secure Storage Solution
Future
Capability to configure unique

IDs for service access
Future
Authenticate SONAS admins

via Kerberos
Requested by RedHat
Future
anonymous LDAP bind
D.E Shaw; strong security concern, but still requested by customer
Reject
AD with LDAPS
SONAS connects to AD via Kerberos, CIFS/RPC, LDAP, CLDAP, NetBIOS and DNS. CBS requested to encrypt LDAP traffic
by supporting LDAPS. This requests has been rejected:
https://fsccsvn.mainz.de.ibm.com/svn/fscc_internal/documents/design/Security/roadmap/Secure%20access%20to%20data%2
0stored%20in%20Windows%20Active%20Directory.pdf
3/8/2012 1:28 PM
Certification to standards like Common Criteria (Level 4), FFIEC, HIPAA, PCI DSS, SOX, GLBA, Data Protection Act, 21 CRF
Part 11, ISACA, Basel II, California Senate Bill 1386 (or SB 1386)
Citi: SONAS admin issues command. Secure officer needs to approve for command execution.
IBM CONFIDENTIAL

Further requirements (other, 2 of 2)

Prio
37
ID
Plan
Title
Description
Future
Cross SONAS system

consistency of username/
groupname/UID/GID/SID
mapping
Provide a capability to configure multiple SONAS systems with the same mapping scheme, if mapping is maintained inside
SONAS and not on an external directory service
Future
Push SONAS auth

configuration
Configure SONAS authentication and ID mapping on one reference SONAS system and push the configuration from their to
multiple other SONAS systems including Panache clients
Future
Allow to configure ACL model

for file system, fileset or NAS
export
SONAS supports multiple ACL models: CIFS ACL, NFSv4 ACL, POSIX bits. Supporting all ACLs models causes interoprability
issues. We might support multiple ACLs modes: (1) 100% CIFS ACL compliance, (2) 100% NFSv4 ACL compliance, (3) 100%
POSIX compliance, (4) mixed support of all models on a best can do basis. NetApp has similar capability.
Future
Kerberized FTP, HTTP, SCP
Current SONAS support kerberized NFS and CIFS only
Future
Automatic termination of idle

SONAS admin sessions
Future
Automatic termination of idle

SONAS NAS access sessions
Future
Support Windows SACLs for

audit of file access
Future
Virus scanning / Integrity

check for SONAS microcode
Future
Monitor and alert unexpected

processes
Future
Built-in intrusion detection
Future
Encrypt logs sent to L3
May contain customer confidential configuration data (e.g. share names, machine names)
Future
Encrypt output of
backupmanagementnode CLI
command
Include AD machine password
3/8/2012 1:28 PM
Check integrity of SONAS software (Linux scripts & executables, configuration files)
IBM CONFIDENTIAL
Conclusions / Recommendations
earlier version
1.
We need to improve our understanding of the NetApp security features and surrounding ISVs
Gain detailed understanding of NetApp security features
Gain detailed understanding of security ISV support for NetApp
Gain detailed understanding of customer security value for NetApp features + ISV ecosystem
There is limited knowledge inside SONAS development and eventually inside whole storage development, but there
is NetApp expertise available in
S&D (NSeries), GTS, GBS (?), SWG (?)
GMU countries (attrition from NetApp to IBM)
For each opportunity (e.g. BAE) understand how NetApp security features and NetApp ISVs support the customer
requirement
Establish a task force, AoT study, etc. to fully understand
(a) NetApp value network (= feature + ISV + use cases)
(b) how NetApp meets customer security requirements in current competitive SONAS opportunities
2.
We need to develop a strategy / vision for IBM file storage security

Strategy / vision must include security features and ISV support and customer use cases
Strategy / vision must cover
Traditional NAS (NetApp)

NetApp is a good role model
Consolidated NAS (SONAS)

Partitioning, federated authentication & ACLs
Distributed NAS (SONAS + Panache) Integration of encryption / TKLM
3.
We need to create and fund a security roadmap which delivers the security strategy for IBM file storage
Roadmap must include enhancements of the SONAS software stack and creation of ISV ecosystem
We do not know the details of the roadmap today, but it is obvious that the delivery of a strong security roadmap
(1) might be a key success factor for IBMs future (file & block !!) storage revenue
(2) requires significant additional development funding for SONAS security
Remember: R&D funding for security roadmap is constrained by mechanics described in The Innovators Dilemma!
38
3/8/2012 1:28 PM
IBM CONFIDENTIAL

SONAS Security Strategy - Security

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SONAS Security Strategy - Security

Diunggah oleh

Hak Cipta:

Format Tersedia

Ulf Troppens

3/8/2012 1:28 PM3/8/2012 1:28 PM

2011 IBM Corporation

Ulf Troppens SONAS Security Strategy

1. What do we support today?

2011 IBM Corporation

Ulf Troppens SONAS Security Strategy

Fields of file security

Elementary security features

Compound security features

Compliance to security standards like

Multiple elementary security features

Elementary and compound security features

2011 IBM Corporation

Ulf Troppens SONAS Security Strategy

Elementary Security Features

2011 IBM Corporation

Ulf Troppens SONAS Security Strategy

Compound Security Features

2011 IBM Corporation

Ulf Troppens SONAS Security Strategy

SONAS Security Features

Disable all Linux daemons not required

AD with automatic id mapping

AD with enhanced automatic id

Use GPFS NFSv4 ACLs for access

Role based access control for admins

Secure LDAP for LDAP authentication

External notification via SNMP

Antivirus for CIFS

External notification via syslog

Improve compliance to IBM ITCS 104

Improve compliance to IBM ITCS 104

Improve compliance to IBM ITCS 104

Ulf Troppens SONAS Security Strategy

SONAS Security Features (2012 Roadmap)

Process for timely response to security

Audit trail for sudo actions

Improve compliance to IBM ITCS 104

Improve compliance to IBM ITCS 104

Roadmap shows the current plan for 2012. Roadmap is

2011 IBM Corporation

Ulf Troppens SONAS Security Strategy

SONAS Security Features (GTS / Compute Cloud only)

Trusted access points

Disallow NAS access via HTTP

Forward internal syslog to external syslog receiver

Eliminated need to customize internal syslog configuration for GTS

Improve compliance to IBM ITCS 104

Improve compliance to IBM ITCS 104

2011 IBM Corporation

Ulf Troppens SONAS Security Strategy

1. What do we support today?

2011 IBM Corporation

Ulf Troppens SONAS Security Strategy

2011 IBM Corporation

Ulf Troppens SONAS Security Strategy

Case study: BAE

Most security requirements fall into

Lots of Security Needed, beyond DIACAP

To meet these requirements, the NAS

The customer can do all this with

Need audit-ability of any file access