15
SECURITY ENGINEERING 2 April 2013 William W. McMillan

SECURITY ENGINEERING 2 April 2013 William W. McMillan

Embed Size (px)

Citation preview

Page 1: SECURITY ENGINEERING 2 April 2013 William W. McMillan

SECURITY ENGINEERING

2 April 2013 William W. McMillan

Page 2: SECURITY ENGINEERING 2 April 2013 William W. McMillan

What are the main reinforcements for breaking into software systems?

Name three distinct populations of people who do this.

Page 3: SECURITY ENGINEERING 2 April 2013 William W. McMillan

Ways People Use the Term “Risk” Something bad that could happen:

“There’s a risk of brake failure.” The probability that something bad could

happen: “The risk of brake failure is 0.01%.”

The cost of something bad happening: “If the brakes fail, we risk passenger

deaths.” We can’t really regulate everyday

language.

Page 4: SECURITY ENGINEERING 2 April 2013 William W. McMillan

Ways to Mitigate Risk

Identify vulnerabilities, threats, and hazards… …then head each one off at the pass.

Establish engineering practices that will lead to reliable software.

The first approach by itself can’t keep the bad guys out. You can’t find every vulnerability or

anticipate every attack.

Page 5: SECURITY ENGINEERING 2 April 2013 William W. McMillan

List three to five typical kinds of attacks on software.

Page 6: SECURITY ENGINEERING 2 April 2013 William W. McMillan

Ways to Attack

abc123

Using Users

SurprisePackages

Picking Locks

Faking/StealingCredentials

Stealing Data

ObservingBehavior

Ganging Up

As a Customer

By Insider

Page 7: SECURITY ENGINEERING 2 April 2013 William W. McMillan

What Can Be Attacked

Operating system Databases Financial records Infrastructure

Communications Dedicated servers

Application code Application data

Page 8: SECURITY ENGINEERING 2 April 2013 William W. McMillan

Describe a recent successful attack on a software system.

Page 9: SECURITY ENGINEERING 2 April 2013 William W. McMillan

User Authentication

Who has access to what? Security policy is defined by client or

management. Need to ensure that you give users the

right level of access. Operational concern. But there are some design implications.

UI should not lead someone to, e.g., accidentally give a new engineer access to the firm’s personnel records.

Email or other communication to user to report transaction, password change, etc.

Page 10: SECURITY ENGINEERING 2 April 2013 William W. McMillan

User Credentials

User name and password Making 3M rich (they make Post-it Notes)

… … which is where many passwords live. Physical cards or other object to plug

into computer Security questions

How hard is it to get people’s mother’s maiden name?

Does a friend know what the model of your first car was?

Biometrics Retinal scans, fingerprints, voice,…

Page 11: SECURITY ENGINEERING 2 April 2013 William W. McMillan

Is it a good idea to require users to change passwords every six months or so?

Should passwords be required to be like this: fH7*iM(sqjX ?

Page 12: SECURITY ENGINEERING 2 April 2013 William W. McMillan

Data Protection

Encryption Fire walls Multiple sites

In case someone corrupts databases at one site.

Checksums, consistency, or other integrity tests

Monitoring of access and traffic User authentication Validation of inputs Providing read-only access when you

can.

Page 13: SECURITY ENGINEERING 2 April 2013 William W. McMillan

Is the client-server model good for protecting data in an organization?

Page 14: SECURITY ENGINEERING 2 April 2013 William W. McMillan

Function Protection

Scan for viruses and worms. Monitor activity. Prevent “backdoors” and “hooks” in

code. Engineering process issue

Beware of reused software. “You don’t know where that thing has

been…” Configure carefully when install or

change. Can change access or visibility.

Page 15: SECURITY ENGINEERING 2 April 2013 William W. McMillan

A small dental practice has a home-grown information system and they’ve hired you to improve its security. What six or so steps would you take before making changes?