Application Security

1
Application Security

• Satish Babu
• Chair, Computer Society
• IEEE Kerala Section
• President, InApp Information Technologies,
  Technopark

2
Rule 0 of Application Security The most
powerful weapon that an attacker has, is the
unsuspecting user...
3
Overview

• Introduction
• Network vs. Application security
• Concepts in cryptography
• Application-level vulnerabilities
• Web vulnerabilities
• Top 10 web vulnerabilities
• Google hacking
• Spam, Spim and Scams
• Conclusion

4
Disclaimer

• This presentation is meant to familiarize
  participants with several security holes that
  exist in commonly-used software so as to
  sensitize them to the need for security
• In the process, it uses tools and techniques
  that, if applied in real-life, may attract
  prosecution
• Any real-world examples used here are only used
  for illustrative purposes and does not imply that
  the particular site has less security than others
• In particular, neither the speaker nor the
  organizers endorse any act such as forced entry
  into computers or the illicit retrieval and
  misuse of user credentials

5
Pre-requisites and desirables

• Pre-requisites
• A sound knowledge of the workings of networks,
  TCP/IP and application-level protocols
• Exposure to a programming language
• Good knowledge of HTML
• Desirable
• Substantial exposure to the web

6
Application and Network Security

• Introduction

7
Security is not a device, but a process. It is
not the destination, but the journey
itself... Anonymous quote
8
Security

• Security was not a concern for developers and
  systems programmers till the early 90s
• However, after the coming of the Internet and the
  spread of distributed applications, security has
  become a major concern
• Security concerns came into the limelight with
  threats as viruses, trojans, worms, and
  crackers, especially as valuable data went on
  the Network

9
Note Values for 2005 projected from first two
quarters
Source http//www.cert.org (CMU)
10
Application security

• These days, security is a concern at two levels
• Network security
• Application security
• The former is concerned about low-level security
  during processes such as transport, routing, and
  other TCP/IP protocol stack operations
• Application security refers to security concerns
  at a higher levelthe level of applications

11
Network security

• In the late '90s, the TCP/IP protocol stack was
  under threat, with various DoS/DDoS/ penetration
  attacks such as
• SYN flood
• UDP bombs
• Finger bombs
• Ping of death
• Broadcast storms
• Smurf/Fraggle attacks
• Nestea, Jolt, Teardrop, Bonk...

12
Application security

• However, the last decade has seen significant
  improvements in Network security
• The crackers or black-hat hackers have
  therefore turned their attention to application
  security
• Application security was not a concern for
  developers until about 2-3 years back
• This presentation will focus on application
  security

13
Type of applications

• For security purposes, applications can be
  classified as client-server or web-based
• The former includes all programmes running on a
  host with no or local back-ends
• These applications are usually written in a
  language such as C/C/Java/VB etc, and have
  different security implications as compared to
  web apps

14
Some common non-web exploits

15
Buffer overflow

• Buffer overflow is a commonly-seen problem with
  programmes written in C, C or assembler
• Java, C or VB are not usually affected by this
  problem
• Many of the system utilities (eg., named,
  sendmail, ftpd) are written in C, and are hence
  vulnerable

16
Buffer overflow

• Buffer overflow happens when data that is too
  large is copied into a buffer
• When this happens, the extra bytes overwrite some
  part of the memory
• What this does depends on the OS and the program,
  but in general, something bad happens

17
Trashing the stack

• What the cracker does goes beyond merely crashing
  the programme
• The cracker overwrites memory in such a way that
  the return address of a function (on the stack)
  is overwritten by the address of a function that
  s/he has written
• Typically this short function spawns a shell.
  Such a shell will have full privileges of the
  original programme

18
printf exploits

• The printf function prints formatted strings. It
  is usually difficult to crash printf, but there
  is one exception
• The n format specifier of printf writes to a
  pointer (all other FSs read a variable and prints
  it). This FS writes the number of strings output
  so far
• The function does not check the validity of the
  destination address

19
Printf exploit

• // vulnerable
• void main(int ac,
• char av)
• printf(av1)
• // Immune
• void main(int ac,
• char av)
• printf(s,av1)

• This code prints out the first command line
  argument, but is vulnerable
• a.out hello
• hello
• a.out nn
• segmentation fault

20
Vulnerable APIs

• The following have been identified as dangerous
  to use
• strcpy,wcscpy,lstrcpy and mbscpy
• strcat, wcscat, lstrcat
• memcpy
• sprintf, printf, scanf, sscanf
• strlen
• gets
• The insertion operator of C

21
Cryptography for security

• Some basic concepts

22
Cryptography

• Cryptography has become a main element of data
  security today
• Cryptography is defined as the science of
  obscuring and de-obscuring data for the purpose
  of rendering it inaccessible during storage and
  transmission
• Cryptography depends on algorithms that are
  computationally expensive to break

23
Security issues

• Confidentiality (message should not be read by
  others)
• Authentication (confirming identity)
• Integrity (message not altered in transit)

24
Storing passwords

• On most situations, security starts with storing
  passwords, as most authentication techniques are
  password or passphrase-based
• Storing passwords in plaintext is highly risky,
  as all passwords will be exposed if an attacker
  gains control to the system
• In most modern operating systems, the password is
  not stored at all

25
Hashes

• Hashes are one-way functions. Any string can be
  hashed to a fixed-length hash, but it is
  impossible to get the original string back from
  the hash
• Well-known hashing algorithms are MD5, SHA1, both
  available in Javascript
• Most OSes store only the hash of the password. It
  is computationally impossible to get the password
  from the hash.
• Authentication is done through hashing the
  password entered by the user and comparing

26
Salted hash

• Hashing is not secure against brute force or
  replay attacks. For additional safety, a random
  number (based on session, time etc) called the
  salt is used
• Rehashing the salt is called salting a hash
• Hash the first string
• Append the salt to the hash
• Hash it again
• Salted hashes are much more secure, as each
  password may be hashed with a different salt,
  thus increasing the computational complexity

27
Encryption

• Encryption refers to transforming data (plain
  text) through a series of arithmetical
  operations into a unreadable form (cipher text)
• Encryption uses a key (usually a string) for
  added security
• The cryptographic strength of the encryption
  depends on the algorithm and the key length

28
Symmetric key crypto

• Both encryption and decryption are done using the
  same key in this case
• Reasonably good security and performance
• But several problems
• transporting the key
• Secure storage of too many keys (one per peer)
• Prone to brute force attacks (a DES message was
  broken in 4 months by brute force). Can be made
  even more secure by sequential encryption (3DES)

29
(No Transcript)
30
Public key crypto

• Public (or asymmetric) key crypto operates with
  two keysone public key and the other private key
• Text that is encrypted with one key can only be
  decrypted with the other key
• A person distributes his public key to all his
  friends (and enemies) who would like to
  communicate with him either directly, or through
  a certifying authority
• He keeps his private key secure, and only known
  to himself

31
(No Transcript)
32
(No Transcript)
33
PK crypto

• There is no need of a secure key exchange as in
  the case of symmetric key crypto
• PK crypto is computationally heavier than
  symmetric key crypto, leading to performance
  problems
• In many cases, a combination of the two is used,
  where the PK is used for secure transmission of
  the symmetric key

34
Digital signatures

• If a message should be readable but not
  modifiable, a digital signature is used to
  authenticate the sender
• Bob writes a message and computes its hash. The
  hash is encrypted with Bob's private key and the
  resulting signature is appended to the message
• Alice confirms that it is Bob who sent the mail,
  by decrypting the signature with Bob's public
  key, recomputing the message hash and comparing
  the two

35
Digital Signatures
36
Digital certificate

• While interacting with unknown parties over the
  web, this scheme is not sufficient. The identity
  of Bob (that it is really Bob and not someone
  else using his name) needs confirmation
• This requires an additional document, a digital
  certificate
• Certificates are usually issued by globally
  trusted agencies

37
Digital certificate

• Consists of
• Issuer's name (eg., Verisign, Thawte)
• Validity duration
• Subject's name and site address
• Subject's public key encrypted with CA's private
  key

38
Digital certificates

• When Alice gets Bob's message, she asks for his
  digital certificate and public key
• She downloads the CA's public key, decrypts the
  certificate to obtain Bob's public key, and
  compares it with the key that she obtained from
  Bob
• This is the basic schema used for SSL

39
SSL/TLS

• SSL secures point-to-point traffic (though not
  necessarily end-to-end traffic)
• SSL can use self-certification, in which case
  users cannot cross-check the server's identity
• A Certifying Agency (CA) issues verifiable
  certificates
• CA's require one or more dedicated IPs, domain
  names, and other information for issuing
  certificates
• Certificates are issued for a valid period, and
  can be revoked

40
A simplified view of SSL
ALICE BOB
Hi, I'm Alice.Who are you?
I'm Bob. Here's my certificate
Prove it!
Alice, this is Bob digestAlice, this is
Bob Bob's PrivKey
If found ok, sends A symmetric keyBob's
PubKey
Decrypts using PrivKey, and starts transmission
using symmetric key
Continues to use the same symmetric key
41
Web exploits

42
The web

• The web was not designed with security in mind
• The typical web user is not very educated, nor
  security conscious
• In fact, even some System Administrators are not
  sufficiently security conscious!
• The wide distribution of access points (eg.,
  cyber cafes) also makes building secure
  applications a challenge
• A large number of applications use the web
  (informational, educational, entertainment,
  transactional, governance...) as transport

43
Common web security myths

• The user will always submit the appropriate
  kind of data
• Javascript will take care of validation
• Our site runs on SSL with 128-bit encryptionso
  we are absolutely safe
• Server side validation is a waste, as we are
  already doing client-side validation

44
Browser proxy tools

• Proxies are employed in many situations such as
  offices and cyber cafes to share an Internet
  connection among many machines
• There are several browser proxies that are
  capable of not only examining data that passes
  through them, but also modifying the data. These
  are a tool for hackers
• Examples are Achilles (Windows) and Paros
  (multiplatform)

45
Common web exploits

• URL manipulation
• Password guessing
• Proxies and man-in-the-middle attack
• HTML comments
• Forgot password implementations
• Keystroke loggers
• SQL injection
• Command injection
• XSS

46
HTTP Basics

• HTTP is based on a series of request-response
  cycles
• Requests are originated by the client, while the
  server sends out the requested resource (provided
  it exists, and user is authorised)
• HTTP is a stateless protocolthe server closes
  the connection immediately after sending out the
  required resource
• Built-in security features of HTTP is very
  minimal and insufficient

47
GET and POST

• Requests are made by the client using either GET
  or POST header methods (there are three more
  methods which are for specialized use)
• In both, the browser sends across a resource
  name, together with optional additional data
  (eg., form data) to the server
• GET is simpler and has size limitations. In
  theory, GET is to ask for information, while POST
  is to contribute information. Programmatically,
  they are almost identical in the new frameworks
  like PHP, ASP or JSP

48
HTML clues

• Programmers may leave clues in the code about
  user names
• In some cases, the passwords can be guessed,
  especially if the hacker knows the victim
  reasonably well

49
Hidden field manipulation

• Hidden fields can easily be seen and modified
  from within a proxy
• Therefore, storing important information (eg.,
  userid, password, PIN) in hidden values is a very
  bad idea

50
Spoofed links in emails

• It is easy to spoof email links in HTML-based
  emails (also used in phishing)
• An innocent-looking link may actually be going
  somewhere dangerous
• There have been cases where entire sites have
  been dynamically displayed through a back-to-back
  connection

51
JavaScript validation

• Some programmers repose too much faith in
  client-side validation such as that using
  JavaScript
• However, such validation becomes totally useless
  in the face of proxies that modify parameters on
  the fly

52
Unprotected admin scripts

• Many sites have admin interfaces for changing
  settings
• All admin interfaces are usually protected using
  password or SSL
• However, sometimes some of the other admin
  components are accessible even without a valid
  login, as the adminstrators think that since no
  link exists, people can't make out that such
  pages exist

53
Weak access control

• If web directories are not given proper access
  privileges, an ordinary form can become
  vulnerable
• This can be used to get contents of sensitive
  files

54
Forgot password scripts

• Many sites have a Forgot password feature that
  often becomes a security flaw
• These scripts are not sufficiently tested as they
  are of low priority
• These days, Forgot password scripts are
  implemented through security questions that make
  it harder to break

55
Weak cookies

• Session handling is done usually through cookies
• However, many server-side programmes created
  cookies in a simplistic manner
• These cookies can be reverse-engineered to hijack
  sessions
• Ideally, session validation should be based on
  cookies IP or some other parameter

56
XSS

• Cross-site scripting is a complex process
• Attacker logs in into an on-line forum
• He makes an entry here that will be read by
  anyone who wants to read it
• Embedded in his routine text entry is a
  ... section which contains
  malicious code.
• He logs out
• The site is visited by some unsuspecting victim
  who clicks the attacker's entry
• The victim's browser executes the malicious code,
  which sends sensitive information to the attacker

57
XSS vulnerable targets

• Targets are
• Bulletin boards
• Blogs
• Chatrooms
• Guest books
• Anything else that reflects browser inputs
  without validation
• Sanitize data (ie., remove HTML, and
  several other characters in postings)

58
Command injection

• Weakly coded applications are vulnerable to
  injection of commands into a form
• Since can Unix take multiple commands in a single
  line, all the user has to do is to enter his
  command after a semicolon (which is a command
  separator)

59
SQL injection

• A serious flaw with dynamically-built SQL queries
• Can result in significant loss of confidentiality
  or even loss of entire database
• Always use PreparedStatement or CallableStatement
  in Java or ADO in .NET
• Validate and Sanitize data before using

60
URL manipulation

• When GET is used for form submission, all the
  fields are exposed in the URL line in the browser
• This makes it easy to change things on the
  submitted query
• Can be avoided by using POST instead of GET
• If GET is required for some reason, then
  cryptographic protection of parameters is required

61
Fail-open authentication

• Hackers armed with proxies can provide unexpected
  inputs to the application (so never trust
  client-side validation alone)
• Some applications are coded in such a way that
  when they fail, they leave the door wide open...!
• This can be a potent tool for the hacker

62
Browser refresh

• Browsers cache entire submissions in their memory
• Even after logout (and session invalidation),
  these can be retrieved by the back key followed
  by a refresh if the browser is not closed

63
Phishing

• A high-tech scam of spoofing trusted sites by
  misleading links (esp. in HTML mail or a link
  like www.ebay.com_at_members.tripod.com)
• Aimed to fool inexperienced (and some
  experienced) users
• Can result in loss of user credentials and
  financial loss

64
(No Transcript)
65
(No Transcript)
66
(No Transcript)
67
(No Transcript)
68
Name similarities

• www.mcrosoft.com
• www.whithouse.org, www.whitehouse.com
• www.ebay.com_at_members.tripod.com
• www.nasa.com
• WWW.VERlSIGN.com
• www.paypa1.com
• https//www.paypal.comacalksdjff_at_KI54fT.WoRlDiSp
  NeTwOrK. CoM/i.CgI? billing_at_yourdomain.com
• 99107101114.comHello

69
Evading phishing

• User awareness (look carefully twice)
• Never click on an email link to go to a financial
  site
• Never respond to financial mail
  immediatelyalways cross check off-line
• Look at the status bar to see whether a link
  points to the real site

70
Keystroke loggers

• Keystroke loggers can be hardware or software
• Software loggers are trojans that log all
  keystrokes into a file (or email it out to the
  perpetrator daily)
• Hardware loggers can be impossible to detect
• These can defeat most of the methods that we
  discussed so far
• More sophisticated techniques are required to
  beat these graphical entry of login (with the
  mouse),

71
Passwords in memory

• Passwords remain in the memory of the computer
  that runs it (even when it can't be displayed in
  the password field)
• If a running programme can be examined by a
  memory scanner, the password can be destroyed
• Even after the programme exits, the password can
  be discovered unless it is explicitly cleared
  programmatically (cat /dev/mem /tmp/mem)

72
Proxies and SSL

• Web proxies can defeat SSL by the classic
  man-in-the-middle strategy
• When the client asks for a https site, the proxy
  in turn contacts the site and gets its
  certificate
• It then gives a validbut self-issuedcertificate
  to the client. Most clients will now pop up a box
  saying the certificate is untrusted (and most
  uneducated users will continue browsing)
• From then on, there are two back-to-back secure
  connections client-proxy and proxy-server

73
Pharming

• Pharming exploits vulnerabilities on DNS servers
  and their caches
• The strategy is to hijack a website's DNS entry,
  thereby redirecting the site to a bogus page,
  even when the user types in the correct name
• Many sites such as ebay.de, hushmail.com and
  panix.com were hijacked like this

74
Evil Twin

• An evil twin is a spoofed wireless hotspot that
  pretends to be legitimate
• This has happened in restaurants, public places
  and even conferences
• In April 2005, fraudsters set up an Evil Twin in
  a conference in London, pretending to be the
  official Wi-Fi providers
• When users connected, not only were their
  passwords stolen, but they were also infected
  with an array of about 45 viruses

75
OWASP Top ten most critical vulnerabilities

76
1. Unvalidated input

• Attackers can tamper with any part of the input,
  including the URL, querystring, headers, cookies,
  form fields and hidden fields
• Resulting vulnerabilities include buffer
  overflow, format string, forced browsing (ie.,
  deep link browsing), injection etc
• Server-side validation is absolutely essential

77
2. Broken access control

• Insecure access control IDs (Eg., admin, manager,
  editor)
• Forced browsing past by-passable deep links
• Path traversal (..\..\target_dir\secret_file)
• Inappropriate file permissions
• Browser caching from insecure locations
  (libraries, cyber cafes)

78
3. Poor session management

• Poor password strength
• No locking after fixed number of wrong logins
• Insecure password change mechanisms
• Plaintext password storage
• Insecure transmission of credentials
• Insecure transmission of session ID
• Passing of credentials in GET

79
4. XSS (Cross-site scripting)

• Can be stored or reflected
• Malicious portions often encoded (including using
  Unicode)
• Any embedded content including ActiveX, VBScript,
  Flash or Shockwave can be malicious
• HTML user input must be sanitized in order to
  prevent this

80
5. Buffer overflows

• Due to inappropriate use of certain C/C
  functions that attack the stack
• Can be detected by a security code review
• Earlier several Internet applications were
  vulnerable (eg., sendmail, named), but now these
  have been fixed

81
6. Injection flaws

• Injection of commands or SQL into forms
• Command injection generally a problem of Perl,
  python and other interpreted languages
• SQL injection is a consequence of näive SQL code
  (dynamic code as opposed to prepared statements)
• Always validate and sanitize user data

82
7. Improper error handling

• Error messages sometimes reveal too much
  information about the platform, server, and
  application
• This can provide clues to enterprising attackers

83
8. Insecure storage

• Storage of sensitive information (credit card
  numbers, PIN numbers) on insecure storages
• Failure to encrypt critical data
• Insecure storage of keys, certificates, passwords
• Poor sources of random numbers
• Poor choice of algorithms
• Attempting to invent own encrypting system
• Failure to include support for encryption key
  changes and other maintenance

84
9. Denial of service

• Difficult to distinguish between attacks and
  genuine requests
• Therefore, difficult to protect against such
  attack
• Fixing process/user quotas for CPU time and
  memory may help

85
10. Insecure configuration mgmt

• Configuration/Deployment management may also have
  problems
• Unpatched flaws in server-side software
• Misconfiguration allows directory listings and
  directory traversal attacks
• Unnecessary files (default, backup, samples..)
• Unnecessary services enabled
• Default out-of-the-box accounts passwords
• Admin/debug functions enabled

86
Why look for back-doors when you can waltz in
through the front door?
Welcome to Google hacking!

87
Google hacking

• As many first-time programmers and administrators
  took to the Internet, most using tools that are
  meant for novices, security lapses have become
  quite common
• Google, through its powerful API, can be used to
  quickly pinpoint such vulnerabilities
• Since Google indexes sites without even the
  administrator noticing, many sites have found
  their sensitive documents available in public

88
Google search operators

• The site operator can be used to list down all
  pages in a given site
• eg., sitehttp//www.microsoft.com XP will
  locate all pages at Microsoft that contains the
  word XP
• The inurl operator locates a word in the URL
  string
• eg., inurlindex.of parent directory gives
  several sites that have inadvertently exposed
  whole directories

89
Google operators

• The same command can be used to locate servers
  with a particular version number (quite handy for
  locating vulnerable releases)
• The query allintitleWelcome to Internet
  Information Server would fetch the list of all
  out-of-the-box installations of IIS
• The filetype operator can show selected file
  types (eg inurledu inurlgrades filetypexls

90
Weak CGI spotting

• There are several weak CGI vulnerabilities that
  can be spotted using Google
• /cgi-bin/web2mail.cgi (mail out /etc/passwd)
• /random_banner/index.cgi?image_list
  alternative_image.listhtml_file../../../../../et
  c/passwd (display passwd as a banner)

91
File spotting

• Some files may contain interesting information
• Personal history and details
• Medical history
• Organizational records
• Financial information
• Google has recently added number spanning
  searches (eg., 15-20), and hackers have already
  used it for searching for credit card numbers
  (visa 4356000000000000-4356999999999999)

92
Spam, Spim, Scamsand cyber terrorism

93
There's a popular saying that the only secure
computer is one that's turned off. Clever, but
false The pretexter simply talks someone into
going into the office and turning that computer
on... Kevin Mitnick, Cracker turned security
consultant
94
Social Engineering

• The weakest link in the security chain is often
  the unprepared user/staff member, who gives out
  seemingly-inoccuous pieces of information
• In most corporate attacks, the attacker uses the
  tools of social engineering, together with good
  planning, an intimate knowledge of the
  environment/technology and audacity
• Kevin Mitnick, the legendary phreaker-cracker has
  outlined the power of social engineering in his
  masterpiece, The Art of Deception

95
Spam

• Spam has become a major consumer of bandwidth,
  disk space and users' time, with imputed costs
  running into millions of dollars
• All kinds of material ride the Net as spam chain
  letters, advertisements, virus hoaxes, scams...
• Never reply to spam, as the spammer now knows
  that he has a valid email ID
• Despite legislation, spam filters and smart mail
  clients (eg., gmail), spam occupies about 30 of
  all email today, growing at about 20 each year

96
Spam and Spim

• At this rate, 99 of all email will be spam by
  the year 2009 !
• Some spammers user automated techniques (eg., a
  graphic image embedded in a spam through a CGI
  script) to separate real email ids from fake ones
• Spim is similar to spam, but the carriers are IMs
  (Instant Messengers)
• Spim is set to treble from 400 million in 2003 to
  1.2 billion this year

97
Scams

• There are several scams that are using the
  Internet and print media to circulate
• Nigeria (419) scam
• Auction fraud
• Patent medication (Cialis, herbal viagra)
• Pump-and-dump stock market scam
• Viruses
• Chain letters (Microsoft will pay you 25)
• Identity theft
• Lottery

98
Scams

• Work from home and make big money
• Health and diet scams
• Spy on anyone
• Get credit card numbers and site passwords
• Scholarship scams
• Telephone billing scam (bills are charged to
  telephone accountsthe lost pet scam)
• Get a college degree
• Get software cheap
• 9/11 donations
• Free computers (cameras, printers...)

99
Auction scams

• Misrepresentation of item or value
• Failure to ship
• Failure to pay (bounced cheques, stolen cards)
• Shilling (artificially boosting bids by
  accomplices)
• Bid shielding (using phony bids to scare away
  real bidders and finally retracting the bid)
• Piracy (of music or other counterfeit material)
• Fencing (selling stolen goods)
• Buy and switch (buying and then returning a
  different, but damaged item)
• Shell auction (no merchandise exists)

100
Identity theft

• When someone appropriates your personal
  information in order to commit fraud or theft
• Credentials (Name, email, address, social
  security number, credit card number) can be
  obtained through a variety of mechanisms
  (including a lost wallet)
• In the West, ID theft can be serious, as the
  fraudster can completely take over the ID (and
  deny the original owner of medical care, bank
  credit and even mail!)

101
Cyberterrorism

• After 9/11, there is substantial attention on the
  use of the Internet by terrorist groups
• These groups use techniques such as steganography
  to multicast messages
• Apart from images and sounds, the latest
  discovery is that secret messages can be hidden
  in in the most common mail--Spam!

102
Conclusions

103
Conclusions

• There are a large number of motivated and
  malicious people who attack sites, be it for
  profit or the thrill
• Until we use better tools, techniques and
  discipline, there is the risk of our sites being
  defaced, used as the base of attacking other
  sites, or worse, losing valuable information
• The age of innocent coding is over, and it is
  time that every site on the Internet paid
  attention to application security

104
References

• Innocent Code A Security Wake-up Call for Web
  Programmers by Sverre H. Huseby
• CERT, http//www.cert.org/
• OWASP, http//www.owasp.org
• Johnny Long, http//www.ihackstuff.com
• The Art of Deception by Kevin Mitnick
• Wikipedia (http//www.wikipedia.org) pages on
  security
• The Ten Immutable Laws of Security at
  http//www.microsoft.com

105
Thank you.