secure engineering n.
Skip this Video
Loading SlideShow in 5 Seconds..
Secure Engineering PowerPoint Presentation
Download Presentation
Secure Engineering

Loading in 2 Seconds...

play fullscreen
1 / 30

Secure Engineering - PowerPoint PPT Presentation

  • Uploaded on

Secure Engineering. Dan Fleck CS 469: Security Engineering. 1. Sources: OWASP_Guide_Project. Secure Web Applications. OWASP Guide to Secure web applications Security Standards (COBIT or ISO17799)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Secure Engineering' - inigo

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
secure engineering

Secure Engineering

Dan Fleck

CS 469: Security Engineering


  • Sources:

Coming up: Secure Web Applications

secure web applications
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


Coming up: Development Methodology

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


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


Coming up: Security Principles

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


Coming up: Minimize Attack Surface

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:


Coming up: Secure Defaults

secure defaults
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?


Coming up: Principle of Least Privilege

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!


Coming up: Principle of Defense in Depth

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

fail securely
Fail securely
  • When failing, fail into a secure state

isAdmin = true;

try {

codeWhichMayFail();isAdmin= isUserInRole( “Administrator” );

}catch (Exception ex) {




Secure or not secure?

Coming up: External systems are insecure

external systems are insecure
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.


Coming up: Separation of duties

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.


Coming up: Do not trust security through obscurity

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 vsiOS?


Coming up: 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)


Coming up: Fix security issues correctly

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


Coming up: Threat Risk Modeling and Objectives

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

document threats
Document Threats
  • Sample threat graph


Coming up: Lots of “threat modeling” templates out there

lots of threat modeling templates out there
Lots of “threat modeling” templates out there
    • Spoofing identity
    • Tampering with data
    • Repudiation
    • Information disclosure
    • Denial of service
    • Elevation of privileges
  • There are others though (CVSS, OCTAVE, AS/NZS…)


Coming up: 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...


Coming up: Countering Phishing

countering phishing
Countering Phishing
  • Some technical approaches
    • sanitizing email attachments
    • anti-adware, malware
  • Best approach: user education


Coming up: Countering Phishing when using email

countering phishing when using e mail
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)

countering phishing when using email cont
Countering Phishing when using email (cont)
  • Reduce Risk - be careful of using “short” obfuscated URLs (like
  • 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., where is your domain, rather than 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)

countering phishing when using email cont1
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)


Coming up: Customer Relations

website guidelines
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 themInvestigate any connections that just pull images


Coming up: Website Design

website guidelines cont
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.


Coming up: Safeguards

safeguards to limit exposure
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).


Coming up: Safeguards

safeguards to limit exposure cont
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

monitor unusual activity
Monitor Unusual Activity
  • Example: Clearing out their accounts
  • What are some others for a banking application?
  • What about a web commerce app?


Coming up: Other things…

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


All of us are smarter than any of us

(but don’t apply this during exams  )

Coming up: Other things…



End of presentation