Secure Engineering
Dan Fleck
CS 469: Security Engineering
1
Coming up: Secure Web Applications
Sources:
https://www.owasp.org/index.php/OWASP_Guide_Project
Secure Web Applications
• OWASP Guide to Secure web applications
• Security Standards (COBIT or ISO17799)
• If you’re publicly traded in most countries, you must have an
information security policy
• If you’re publicly traded in the US, you must have an information
security policy which is compliant with SOX requirements, which
generally means COBIT controls
• If you’re privately held, but have more than a few employees or
coders, you probably need one
• Popular FOSS projects, which are not typical organizations, should
also have an information security policy
2
Coming up: Development Methodology
Development Methodology
Attributes to look for in a development methodology:
• Strong acceptance of design, testing and documentation
• Places where security controls (such as threat risk analysis,
peer reviews, code reviews, etc) can be slotted in
• Works for the organization’s size and maturity
• Has the potential to reduce the current error rate and improve
developer productivity
The choice of development methodology is not as important as simply
having one.
Coming up: Attackers
3
Attackers
From most likely and damaging to least…
• Disgruntled staff or developers
• “Drive by” attacks, such as side effects or direct consequences
of a virus, worm or Trojan attack
• Motivated criminal attackers, such as organized crime
• Criminal attackers without motive against your organization,
such as defacers
• Script kiddies
4
Coming up: Security Principles
Security Principles
•
•
•
•
•
•
•
•
•
•
Minimize Attack Surface
Secure defaults
Principle of least privilege
Principle of defense in depth
Fail securely
External Systems are insecure
Separation of duties
Do not trust security through obscurity
Simplicity
Fix security issues correctly
5
Coming up: Minimize Attack Surface
Minimize Attack Surface
• Every feature in your system adds to the attack surface
• Reduce risk by reducing attack surface
• Example: Web application has inline help with a search
function
•
•
•
•
May be vulnerable to SQL injection
Reduce: limit feature to authorized users
Reduce: use validation routines on input SQL
Eliminate: Re-write UI to eliminate need for search function!
• How to estimate the attack surface:
https://www.owasp.org/index.php/Attack_Surface_Analysis_Cheat_Sheet
Coming up: Secure Defaults
6
Secure Defaults
• Make the “out of the box” user experience good, but secure!
• Example:
• default password aging ON
• default password complexity ON
•
•
•
•
Does your browser do this?
Does Facebook?
Why or why not?
Does Ubuntu? https://www.eff.org/deeplinks/2012/10/privacy-ubuntu-1210-amazon-ads-and-data-leaks
7
Coming up: Principle of Least Privilege
Principle of Least Privilege
• Users (accounts) should have the least amount of privileges
needed to do their job
• Including: CPU limits, memory limits, network and file system
permissions
• Example: If a middleware server only requires network access,
ability to read the DB and ability to write to log files, that is
ALL it should be able to do!
8
Coming up: Principle of Defense in Depth
Principle of Defense in Depth
• Controlling defense by using multiple, different, independent
approaches is always preferable
• Layers of defenses good when possible
• Example: Flawed user admin interface harder to exploit if it
correctly gates access to production management networks
(isolation), checks for user authorization, and logs all access
• Example: How do you protect your computer?
Anti-virus, usernames/passwords, IDS, firewall,
encryption of important files, biometrics(?)
Coming up: Fail securely
9
Fail securely
• When failing, fail into a secure state
isAdmin = true;
try {
codeWhichMayFail();
isAdmin = isUserInRole( “Administrator” );
}
catch (Exception ex) {
log.write(ex.toString());
}
Secure or not secure?
Coming up: External systems are insecure
10
External systems are insecure
• If your system uses a third party system, assume it’s not as
secure as you.
• They have different constraints, different motivations, etc…
• Check all data they send. Assume it’s not trusted.
11
Coming up: Separation of duties
Separation of duties
• Make sure multiple users are needed to perform secure tasks.
• Typically, administrators have special privileges, so they should
NOT be users also.
• Example: An admin can turn the system on/off and change the
password policies. Thus, they should not have access to login
to the system as a privileged user to buy items on behalf of
users.
12
Coming up: Do not trust security through obscurity
Do not trust security through obscurity
• Security should be reliant on keeping secrets
• Obscurity is a weak control and almost always fails when it’s
the only one in place. You can use it, but NOT as the only idea.
• Example: security of an application should NOT be reliant on
keeping the source secret. Does this happen?
• What’s more secure, Windows or Linux?  Why do you think?
What about Android vs iOS?
13
Coming up: Simplicity
Simplicity
• Generally, simplicity helps reduce attack surface
• Complex approaches frequently cause holes and frequently
are only in place to handle “future” expansion that may never
happen.
• Code is done when it works… stop coding! (This is also a
software engineering principle)
14
Coming up: Fix security issues correctly
Fix security issues correctly
• When security issues are found, check all places they may be.
• Specifically, if found in common code or design patterns being
used the same code problem may be in multiple places
• Example: A user finds by manipulating cookies they can view
another user’s balance. Fixing the problem is simple, but the
same cookie handling code may be in multiple other places
within the application
15
Coming up: Threat Risk Modeling and Objectives
Threat Risk Modeling and Objectives
Identity: does this application protect user’s
identity from misuse?
Reputation: the loss of reputation derived from the
application being misused or successfully attacked
Financial: the level of risk the organization is
prepared to stake in remediation potential financial
loss.
Privacy and regulatory: to what extent shall
applications protect user’s data.
Forum software is by its nature public, but a tax
program is inherently bound up
in tax regulation and privacy legislation in most
countries
Availability guarantees: is this software required to
be available by SLA or similar agreement?
Is it nationally protected infrastructure? To what
level will the application need to be available?
Coming up: Document Threats
16
Document Threats
• Sample threat graph
17
Coming up: Lots of “threat modeling” templates out there
Lots of “threat modeling” templates out
there
• STRIDE:
•
•
•
•
•
•
Spoofing identity
Tampering with data
Repudiation
Information disclosure
Denial of service
Elevation of privileges
• There are others though (CVSS, OCTAVE, AS/NZS…)
18
Coming up: Phishing
Phishing
• 5% of users are lured into these attacks! [2005]
• Delivery via web site, e-mail or instant message, the attack asks users to click on a link
to “re-validate” or “re-activate” their account. The link displays a believable facsimile of
your site and brand to con users into submitting private details
• Sends a threatening e-mail to users telling them that the user has attacked the sender.
There’s a link in the e-mail which asks users to provide personal details
• Installs spyware that watches for certain bank URLs to be typed, and when typed, up
pops a believable form that asks the users for their private details
• Installs spyware that watches for POST data, such as usernames and passwords, which is
then sent onto a third party system
• Installs spyware that dredges the host PC for information from caches and cookies
• “Urgent” messages that the user’s account has been compromised, and they need to
take some sort of action to “clear it up”
• Messages from the “Security” section asking the victim to check their account as
someone illegally accessed it on this date. Just click this trusty link...
19
Coming up: Countering Phishing
Countering Phishing
• Some technical approaches
• sanitizing email attachments
• anti-adware, malware
• Best approach: user education
20
Coming up: Countering Phishing when using email
Countering Phishing when using email
• Tell users every single time you communicate with them,
that:
•
•
•
•
they must type your URL into their browser to access your site
you don’t provide links for them to click
you will never ask them for their secrets
and if they receive any such messages, they should immediately
report any such e-mail to you, and you will forward that on to
their local law enforcement agencies
• Consistent branding – don’t send e-mail that references
another company or domain.
• Reduce Risk - don’t send e-mail at all.
• Reduce Risk - don’t send HTML e-mail.
Coming up: Countering Phishing when using email (cont)
21
Countering Phishing when using email
(cont)
• Reduce Risk - be careful of using “short” obfuscated URLs (like
http://redir.example.com/f45jgk)
• Increase trust - Many large organizations outsource customer
communications to third parties. Work with these
organizations to make all e-mail communications appear to
come from your organization (i.e., crm.example.com where
example.com is your domain, rather than
smtp34.massmailer.com or even worse, just an IP address).
• Increase trust - set up a Sender Policy Framework (SPF) record
in your DNS to validate your SMTP servers. Phishing e-mails
not sent from servers listed in your SPF records will be
rejected by SPF aware MTAs.
Coming up: Countering Phishing when using email (cont)
22
Countering Phishing when using email
(cont)
• Increase trust – sign email
• Incident Response - Don’t send users e-mail notification
that their account has been locked or fraud has occurred
– if that has happened, just lock their accounts and
provide a telephone number or e-mail address for them
to contact you (or even better, ring the user)
23
Coming up: Customer Relations
Website Guidelines
• Never ask customers for their secrets
• Fix XSS issues
• Don’t use pop-ups. They confuse people and make it easier for
attackers
• Don’t use frames – attackers can re-use them
• Enforce local referrers for images and other resource – this forces
attackers to copy them, and possibly mess them up or forget to
update when you change them
Investigate any connections that just pull images
Coming up: Website Design
24
Website Guidelines (cont)
• Don’t be the source of identity theft – If you maintain
information about the users, don’t present this data to users.
• Example: Internet Banking solutions may allow users to
update their physical address records. There is no point in
displaying the current address within the application, so the
Internet Banking solution’s database doesn’t need to hold
address data – only back end systems do.
25
Coming up: Safeguards
Safeguards to limit exposure
• If an account is opened, but not used for a period of time (say
a week or a month), disable it.
• Verify the registration info. Example: does the ZIP code mean
California, but the phone number come from New York?
• Daily limits, particularly for unverified customers.
• Settlement periods for offsite transactions to allow users time
to repudiate transactions.
• Only deliver goods to the customer’s home country and
address as per their billing information
• Only deliver goods to verified customers (or consider a limit
for such transactions).
26
Coming up: Safeguards
Safeguards to limit exposure (cont)
• If your application allows updates to e-mail addresses or
physical addresses, send a notification to both the new and
old addresses when the key contact details change.
• Do not send existing or permanent passwords via e-mails or
physical mail. Use one time, time limited verifiers instead.
• Implement SMS or e-mail notification of account activities,
particularly those involving transfers and change of address or
phone details.
• Prevent too many transactions from the same user being
performed in a certain period of time – this slows down
automated attacks.
• Two factor authentication for highly sensitive or high value
transactional accounts.
Coming up: Monitor Unusual Activity
27
Monitor Unusual Activity
• Example: Clearing out their accounts
• What are some others for a banking application?
• What about a web commerce app?
28
Coming up: Other things…
Other things…
• There are more things to do… secure standards
•
•
•
•
Network security
Secure coding
Cryptography
(all the things we discussed in the semester! )
• etc, etc… always learn, always research best practices
• https://www.owasp.org/index.php/Cheat_Sheets
• https://www.owasp.org/index.php/Category:OWASP_Application_Secur
ity_Verification_Standard_Project
All of us are smarter than any of us
(but don’t apply this during exams  )
Coming up: Other things…
29
30
End of presentation