SLA's and rules of thumb

From theDailyWtf, a story about availability & SLA’s that’s worth a read about an impossible availability/SLA conundrum. It’s a good lead in to a couple of my rules of thumb.

“If you add a nine to the availability requirement, you’ll add a zero to the price.”

In other words, to go from 99.9% to 99.99% (adding a nine to the availability requirement), you’ll increase the cost of the project by a factor of 10 (adding a zero to the cost).

There is a certain symmetry to this. Assume that it’ll cost 20,000 to build the system to support three nines, then:

99.9 = 20,000
99.99 = 200,000
99.999 = 2,000,000

The other rule of thumb that this brings up is

Each technology in the stack must be designed for one nine more than the overall system availability.

This one is simple in concept. If the whole system must have three nines, then each technology in the stack (DNS, WAN, firewalls, load balancers, switches, routers, servers, databases, storage, power, cooling, etc.) must be designed for four nines. Why? ‘cause your stack has about 10 technologies in a serial dependency chain, and each one of them contributes to the overall MTBF/MTTR. Of course you can over-design some layers of the stack and ‘reserve’ some outage time for other layers of the stack, but in the end, it all has to add up.

Obviously these are really, really, really rough estimates, but for a simple rule of thumb to use to get business units and IT work groups thinking about the cost and complexity of providing high availability, it’s close enough. When it comes time to sign the SLA, you will have to have real numbers.

Via The Networker Blog

More thoughts on availability, MTTR and MTBF:

Spam domain name stats

http://gcn.com/articles/2009/05/18/cybereye-spam-domain-registry.aspx?s=security_180509

What to monitor on a server

-binary md5 sums
-disk usage
-who is logged on
-running processes
-recently altered files
-files without user or group ownership
-files with global write perms or setuid or setgid

If only...

Secured email for exchange

Boldon James Safemail products

http://www.boldonjames.com/SAFEmail-for-SIE-231

Microsoft S/MIME implementation

http://searchexchange.techtarget.com/generic/0,,sid43_gci1252311,00.html

Security Labels

http://msdn.microsoft.com/en-us/library/aa140148(office.10).aspx



Microsoft Rights Management Solutions for Exchange 2007

http://www.simple-talk.com/exchange/exchange-articles/configuring-exchange-server-2007-to-support-information-rights-management/

PXE boot links

Links for PXE boot, especially for Clonezilla

http://clonezilla.org/clonezilla-live/livepxe.php

http://docs.fedoraproject.org/install-guide/f10/en_US/sn-booting-from-pxe.html

http://linux-sxs.org/internet_serving/pxeboot.html

http://myy.helia.fi/~karte/pxe.html

Audit trail of SSH sessions

Record SSH sessions at client and at server

http://www.jms1.net/ssh-record.shtml

Chroot users in shell so that all they can do is SSH onwards

http://olivier.sessink.nl/jailkit/howtos_ssh_only.html

Privilege user product

Product to manage privilege users, passwords and their accesses

http://www.symark.com/products/padoverview.html

Free online Information Security and computer science courses

http://www.computer-colleges.com/blog/2009/diy-ciss-degree-100-open-courses-on-computer-information-systems-and-security/

Virtual host and DNS names enumeration techniques

http://lab.lonerunners.net/blog/virtual-host-and-dns-names-enumeration-techniques

Web application security test check list

taken from http://pajhome.org.uk/security/webchecks.html

Authentication
Logging in with an invalid user name does not reveal whether the user exists
Accounts are locked after a number of failed logins
An attacker cannot reset the lockout (e.g. by removing cookies)
Can't easily lockout an account to cause a denial of service
After login a redirect is issued, to prevent refresh attacks
Both "change password" and "logout" functions are provided
User is informed of last login time
Change password requires provision of old password
Passwords are proactively checked for strength
Password is never revealed (e.g. in the source of change password)

Session Management
Session tokens are at least 128-bit
Session tokens are unpredictable
A new session is allocated at login (i.e. session fixation is prevented)
Logout invalidates the session token on the server
Cookie has "secure" and "httponly" options set and is non-persistent
Sessions have an inactivity timeout
Sessions have an absolute timeout

Injection Attacks
Cross-site scripting
HTTP response splitting
SQL injection
LIKE pattern injection
LDAP injection
XPATH injection
Mail header injection
Directory traversal
Null-byte injection
Shell script / batch injection
Server-side script injection (PHP, Perl, etc.)
XML injection
Try to bypass filters using over-long utf-8 encodings
Try to bypass filters using wide-ascii, or other unicode equivalents

Content Checks
No script tags reference resources on other servers
Use of eval, document.write, innerHTML, etc. does not cause XSS
Comments in files do not reveal sensitive information
Frames/iframes, if used, have frame spoofing protection
autocomplete=off is set on all forms asking for personal information
Private IP addresses

Server Side Script Behaviour
Arbitrary redirection
Arbitrary message inclusion
File upload features restrict uploaded content to prevent compromise
JavaScript Hijacking
Scripts that cause write actions require POST with a CSRF token
Scripts that act as an open proxy or mail relay
Exponential format accepted
Server compromise by uploading XML that sources a stylesheet
Source code disclosure through scripts that allow read access to files

Authorization
All protected resources check for a valid session
All protected resources check for user permissions (forced browing)
Parameter tampering does not allow access to others' data
Page-to-page flow is correctly enforced where required
Form POST targets perform the same authorization as form views

Miscellaneous
cache-control: private or stronger is used on sensitive pages
All client-side validation is repeated on the server
Site supports HTTPS, and sensitive pages forbid HTTP access
All pages are displayed with status and address bars
All URLs are expected from a customer's point of view
No "Mixture of secure and insecure content" warnings

Server Configuration
There are no "orphaned" files (exist on the web server, but not linked)
No backup versions of files are accessible (may reveal source code)
No common insecure scripts (e.g. snoop servlet) are accessible
Error messages do not provide overly-detailed information

Special Cases
Dynamic login questions: question cannot be changed by the user
Application forms: restarting a transcation doesn't leak information
Smoke & mirrors: generated emails are appropriately protected
Domain auth: domain accounts cannot be locked out from the internet
Forgotten password: understand any information leaked or risks created

SSL Client Certificates
Does login check username matches certificate?
Can you lock out an account without holding the certificate?
Is certificate required for every request?
Does it check the certificate matches the session ID?
Can you login using a self-signed certificate?
Are test/pre-prod certicates separated from live?

Nested Web Service
Is the WSDL file accessible?
Does access to the web service require a web session?
Does it check the web session user matches the WS user?
Also, most of this checklist also applies to the web service.