This article focuses on Amazon’s Web Services: Risk and Compliance white paper published in May 2011

Amazon provides AWS control and compliance documentation which customers can use and integrate with their own mechanisms (which Amazon calls the new distributed control environment), however, Amazon does not expose or make public its security platform configurations as customer don’t and shouldn’t communicate their use and configurations to AWS.

The AWS SAS 70 Type II certification provides reasonable assurance that information security policies have been implemented and communicated throughout the organization. These include appropriate access restrictions both at logical and physical levels, patch management at all levels, and data handling procedures such as, change management, integrity and redundancy. This means that internal employees are also under a stringent access control mechanism. Environmental safeguards are also implemented and provide the necessary assurance in case of major physical disasters. In an SAS 70 type report that AWS publishes, one can verify the operating effectiveness of controls that fall under this certification. These controls are checked by external auditors so if your provider is SAS 70 Type II certified then you know which controls are in place by verifying the audit report.

In case of AWS, the same applies to other certifications such as, ISO 27001 and PCI DSS. With the ISO 27001 certification AWS complies with a broad, comprehensive security standards and general control compliance. With PCI DSS (Payment Card Industry, Data security Standard) AWS complies with a wide range of specific controls required by the US government agencies. In addition, AWS has been certified as compliant with certain FISMA (Federal Information Security Management Act).

Who owns which controls for cloud-deployed infrastructure?

AWS controls the physical part of the deployment according to SAS 70 Type requirements. The customer controls the remaining parts of the setup including connections and transmission. Customers can request an SAS 70 Type II report that details all physical and environmental controls, after signing a non-disclosure agreement with Amazon. Hence, customers cannot visit the data center but need to rely on what’s written down in the SAS 70 report. This report and the ISO 27001 are the only artifacts the customer can review for audit and compliance purposes. This also applies to SOX (Sarbanes-Oxley) and HIPAA compliance, while the rest of controls or better the logical controls must be taken care of by the customer.

Customer Data location

The customer has full control of the movement of data within AWS regions. Data replication for S3 data objects is done within the regional cluster in which the data is stored and is not replicated to other data centers clusters in other regions.

Customers’ data and servers are logically isolated from other customers by default. The isolation or segregation is driven by security control features which prevent customers from accessing the physical layer. This architecture is found to be compliant with all requirements of PCI DSS version 2.

Legal

Customers are responsible for the legal implications involving the identification, collection, processing, analysis, and production of electronic documents they store or process, however, AWS can assist customers upon requests.
Only independent and competent auditors are allowed to visit and inspect the data center’s compliance to the above mentioned standards. A third-party auditor can be engaged by customers to perform such checks. Customer with non-disclosure agreement with Amazon may request a copy of the SAS 70 Type II report.

AWS commits to an annual uptime percentage of at least 99.95% and a monthly uptime of at least 99.99%. Data stored in S3 is designed to provide 99.999999999% durability and 99.99% availability of objects over a given year. Service credits are provided in the case these availability metrics are not met. Note, that AWS operates a business continuity program and provides customers with the necessary capabilities to implement a robust continuity plan.

Read the full article here.

In addition to PCI DSS Level 1 compliance, Amazon AWS achieved ISO 27001 certification. The ISO 27001/27002 standard defines security requirements and best practices for managing the company and customer information. Amazon states that the AWS ISO 27001 certification includes all AWS data centers in all regions worldwide and they have established a formal program to maintain the certification.

Securing the IT environment is not a task that is defined once and carried out for the life time of the environment but it is an ongoing process of adjustment (updating items) while executing routine checks.  Whether you are a senior executive or security officer in a large organization or an IT Manager in a small enterprise you need to have a security checklist that is dynamic.  While, such a checklist is used to review that all parts of the IT environment are dealt with, the same checklist would tell you that certain areas have become obsolete while others needs further hardening. Reviewing these checks with the responsible IT staff would also turn up new areas that may be missing from the list.

A high-level security checklist like the one below is not intended to deal with the implementation details of the security controls but it can be extended or linked to other documents. It is a sample checklist that can be used as a starting point!

Physical security:

1. Access to server room
2. Access procedures & guidelines
3. Redundant & storage hardware – ex: RAID, backup drives, etc.
4. Disable unused network points
5. CCTV control / theft & fire systems
6. Mobile workers guidelines for handhelds/laptops – ex: usage policy
7. Inventory of all hardware
8. …

Network security:

1. Network Switches configuration – ex: replace default settings
2. Monitor network traffic – ex: performance issues due to malicious scan tools
3. Monitor Internet traffic – (company policy!)
4. Allowed Protocols – ex: SNMP, community strings settings & permissions
5. DMZ setup – ex: servers in DMZ should not store internal IPs
6. Firewall configuration – ex: allowed/blocked ports, secure vpn access, etc
7. IDS or IPS configuration if implemented
8. …

Wireless Network:

1. WAP configuration – ex: replace default settings, such as, SSID name
2. Shared key management – ex: centralized, expiry rules, complexity
3. Additional security – ex: disable SSID broadcasts, use Https, Mac filtering, etc
4. …

Application Servers:

1. Mail servers configuration – ex: open relay!, antivirus solution, etc.
2. Web servers configuration – ex: disable unused services/accounts, etc.
3. Database servers configuration – ex: db admin account, logs, etc.
4. DNS servers configuration – ex: zone transfer, cache settings, etc.
5. File servers – ex: ACL, file shares, antivirus, etc.
6. AD configuration – ex: security group policies, ACL, etc.
7. Updates mechanism – ex: systems and applications updates, notification, etc.
8. Logs – ex: logs are enabled, collect/review logs
9. Remote admin – ex: SSH, secure RDP, etc.
10. Admin scripts – ex: passwords in clear text!
11. Monitoring mechanism – ex: notify when services are down
12. …

Client Workstations:

1. Software updates distribution – ex: auto vs manual updates, central distribution
2. Antivirus solution – ex: cannot be disabled, auto updates, etc.
3. Computer Policies – ex: lock idle workstations, installation permissions, etc.
4. Hardware usage policies – ex: lock unused ports, media usage, etc.
5. Software inventory – ex: applications installed with version numbers
6. User access permissions – ex: dis/allow administrator privileges!
7. Password policy – ex: strong but not too complicated
8. …

Others:

1. Staff education – ex: ethics, security awareness, etc.
2. IT personnel training – ex: training program
3. Data non-disclosure agreement -
4. Social media usage policy – ex: facebook, personal blogs, etc.
5. Other policies….

The above checklist is not an exhaustive one but should give you a head start. Hence, any additions that you may consider important are welcomed. You may submit them as comments.

Frameworks help organizations build an underlying structure that deals with the strategy, the tactical and the operational aspects of security and risks. No single framework is a perfect match and hence, a better approach would be to review a couple of frameworks such as, Cobit, ISO or ITIL and use parts where appropriate.  It is recommended to mix, match and personalize frameworks as to create your own structure. Common sense within a framework is necessary and will drive consistency.

 
IT risks must be put in the context of the big picture and not isolated from the rest of the organization. They may fall in different categories or levels but their impact is always linked directly or indirectly to the business. An organization must integrate risk management with IT Governance and compliance, whether they are external laws and regulations and/or internal corporate policies and procedures.

What kind of Risk levels we find in an organization?

Lowest level isolated type of risks may happen on a day-to-day basis.  User errors are the most common, however, IT related risks may be present in badly configured servers or setups, insecure project tasks, etc. The lack of security awareness and education among the employees will increase the probability of risks. Various tools and controls can be used to minimize these risks.

A combination of low level risks would comprise the organization’s infrastructure security. The impact is higher as it starts disrupting business units. At this level of risks we find project failures, vulnerable infrastructure, violation of SLAs by vendors, etc. The implementation of adequate controls and standards is a must at this level.

A combination of failed projects, violated SLAs and infrastructure vulnerabilities will lead to enterprise level disruption. At this level, apart from the business disruption which means financial losses, the organization may suffer bad reputation as well!

At the highest level of risks we find elements tied to the business such as, market perception, strategic failures and regulatory compliance.  The impact at this level is critical as an organization may lose its market share and ruin the business, can be fined and make it to the news headlines!

A customer (Cardholder) is purchasing a product form a merchant who accepts credit card on-line payments. The merchant uses a third-party organization (called the acquirer) that provides card processing services. Customers obtain their credit cards from an organization (called issuer) such as, banks or financial institutions. There are various brands (card associations) of credit card networks such as, VISA, MasterCard, etc. These networks act as a gateway between the third-party company (acquirer) servicing the merchants on-line payment and the bank or financial institution (issuer) for authorizing and funding transactions.

The payment process goes through the following steps:

1. The customer pays for a purchase from the merchant on-line store
2. The acquirer verifies with the bank that the card number & transaction amount are both valid and then processes the transaction – transaction authorized
3. Transaction is stored in a batch for later processing by the acquirer
4. Transactions batch is sent to the bank by the acquirer using the respective card association network, which debits the customer accounts and credits the acquirer – acquirer has been paid for all transactions
5. The acquirer pays the merchant, less the processing fee

Credit card companies and banks can be trusted, hopefully! But what security controls are in place for the merchants and acquirers setups? We need a secure process, in other words, a mechanism that oversees that the cardholder’s data is stored, processed and transmitted securely from the Merchant’s website to the Bank.

Payment Card Industry (PCI) Data Security Standard (DSS) governs all the security procedures that all entities involved should adhere to. It started with the major card associations having their own security programs and progressed to a combined effort to develop the PCI standard and council. Apart from acquirers and issuers as PCIs’ member organizations we find service providers. Service providers are companies that provide card related services to acquirers and issuers.

PCI compliance requirements are based on different levels where such levels relate to the volume of credit card transactions performed annually. For example, merchants with more than 6 million annual transactions fall under level 1 while major payment gateways are at level 1 in the service provider’s category. However, a small merchant with a small amount of transactions annually but with a history of data breaches can be moved to level 1. All levels carry the same security requirements, with top levels having more stringent validation requirements. For example, Level 1 requires that merchants or service providers meet the DSS standard, conduct and pass yearly penetration tests, quarterly scans and pass a yearly audit by external auditors. Lower levels have less firm validation requirements.

When we say security requirements we mean that entities should install and maintain a firewall configuration to protect cardholder data, use strong passwords, restrict logical and physical access to data, use updated anti-virus software on their systems, develop and maintain secure systems, protect cardholder data, etc. The list goes on not only to the internal environment but to the cardholder data overall environment which can be a networked system connected to a public network or an off-site data storage service. Most audits fail because merchants or service providers fail to protect stored data according to these requirements!

 
So what is SAS 70 (Statement on Auditing Standard 70) Audit? – The AICPA (American Institute of Certified Public Accountants) responsible body defines it as “Report on the Processing of Transactions by Service Organizations” where professional standards are set up for a service auditor that audits and assesses internal controls of a service organization. At the end of the audit, the service auditor issues an important report called the “Service Auditor’s Report”

Now there two types of SAS 70 audits, Type I and Type II. Type I focuses on the validity of the controls in operation and that they according the specified control objectives objectives while Type II enhances Type I by checking that these controls are actually in place and being executed by the service provider.

In other words, a SAS 70 Audit is an in-depth examination of a service provider control objectives and control activities, including IT controls! Briefly, a service provider must have adequate controls and safeguards over their customers’ data in order to be able to achieve this certificate. However, SAS 70 Audit is slightly flexible and service provider/auditor dependant. That is, you may have customers that may agree or disagree with Amazon’s control objectives or operational standards!

 SAS 70 Type II may be seen as the basis for future more rigid certifications. It may lack some important aspects of security but surely it examines operational performance and the service’s ability to safeguard customer data and many hosting organizations are achieving it.

I have read many expert articles stating that SAS 70 is limited to policies and procedures inside data centers and it does not cover major security weaknesses, such as, personnel unintentional errors. This is quite a pro cloud computing statement. Why? Would an organization (with in-house solutions) take their IT staff (individual) to court in the event of data mishandling? They might and if they do, do they will be able to be paid for the lost revenue/damages from an individual? However, an organization being a customer of a service provider would take that service provider to court in case their data is mishandled. With cloud computing providers, you have higher assurance of getting something back when terrible incidents happen.

1. The application or wizard allows you to set verification of a backup job – tick the verify check box
2. Enable logging features – make sure you know the log files location
3. The application allows you to encrypt backed up data with a password if your destination location is a remote storage host or removable media such as, pen drives – dual password entry text box
4. Enable job status features such as, completion reports – check for failures or warnings

If these options are not presented to you in the application wizard then go and look for them before you start the job. Although, the verification mechanism was more intended to verify data integrity when backing up to tape media, it is still a useful check for all kind of media.

Another important task that I recommend you to perform from time to time is a restore test operation. Select a previous backup set and perform a restore operation to an alternate location (if you restore to the original location, remember you would overwrite your recent files with older ones). After a test restore operation check that the restored files are not corrupted such as, opening a word document or spreadsheet and verify that the data is complete and accessible.

email notification

The native backup utility found on Windows servers is one cool application that has saved many SMBs real cash!  Apart from fulfilling its main functionality, it is found to be very reliable and effective. Problems arise when extra features are required such as, backing up to external storage devices and/or utilizing advanced backup features! One useful feature that is standard in purchasable applications is email notification of backup jobs. The script below gives you that functionality!!!! It’s free and simple to implement!!!!

The implementation steps of the script are as follows:

1. Create a backup job using Windows backup – Start/All Programs/Accessories/System Tools/Backup and set a job schedule
2. Open the window Scheduled Tasks – Start/Control Panel/Scheduled Tasks and find the newly created scheduled job.
3. From the properties window of this job copy the highlighted text from the Run text field
4. Copy this text in a new batch file called ‘mybackup.bat’ (any name you like without quotes)
5. Take a note of the batch file location and enter the full path in the Run text field of step 3 ex: c:\documents\mybackup.bat
6. Close the properties window by clicking OK and enter an admin password if prompted
7. Add the sample script shown below in the batch file after the text entered in step 4
8. Edit the script text to reflect your email & path settings

Sample script

Copied text from step 3 goes here

@echo off
set Sender=”source email addess”
set Receiver=”your email address”
set Host=”IP address of source email server”
set Subject=”Backup name/title”

set logdir=”%USERPROFILE%\Local Settings\Application Data\Microsoft\Windows NT\NTBackup\data”
REM ex – C:\Documents and Settings\administrator\ for %USERPROFILE%
set result=”%temp%\latestlog.txt”

pushd %logdir%
for /f “tokens=1 delims=” %%I in (‘dir /B /O-D’) do (
 if “%%~xI”==”.log” (
   type “%%~fI” > %result%
   goto :end
   )
 )
:end
popd

c:\windows\system32\blat.exe %result% -f %Sender% -to %Receiver% -server %Host% -subject %Subject%
del /q /f “%result%”

explanation

Explanation of the sample script:

 pushd
==> stores the current directory for use by the POPD command, then change to the specified directory

for /f “tokens=1 delims=” %%I in (‘dir /B /O-D’) do
=> parse each line of the directory listing (log files) and get the name of each file one by one

dir /B /O-D  ==> remove heading info from directory list, and list files by date in reverse order

until
if “%%~xI”==”.log”
==>if the current file (its extension only) is .log

then
type “%%~fI” > %result%
==> then copy the contents of the current log file to the variable file latestlog.txt

c:\windows\system32\blat.exe  ==> Blat is a Win32 command line utility that sends eMail using SMTP – http://www.blat.net/?docs/credits.html