1

Steve Chenoweth

Tuesday, 10/18/11

Week 7, Day 2

Right – One view of the layers of ingredients to an enterprise security program. From www.451group.com/security/451_security.php.Background – From http://brooknovak.wordpress.com/2009/07/28/webkit-clipboard-security-hole/

CSSE 477 – Intro to Security

2

Today

• How to do Project 5…• Get ideas from “implementers” on “what should be

more secure.”• Software security – this

– SA Ch 4, pp 85-88 (Security scenarios) & Ch 5, pp. 116-118 (Security tactics)

– More in depth – take CSSE 442 Computer Security (usually taught in winter term – and many of you are signed up!).

– Security also is discussed in these courses:• CSSE 332 Operating Systems • CSSE 432 Computer Networks • CSSE 433 Advanced Database Systems

3

Coming up…

Today: • Show testability results in class• Project 5 (security) ideas turned in tonight

Thursday: • Discuss software product lines (cntd from

CSSE 375 intro)• Team time to work on the security project

4

We next pick security from Bass’s QA list…

• Bass’s list of six, from the inside back cover of his book:– Availability– Modifiability– Performance– Security– Testability– Usability

5

And here’s the project about it:On the project where you were designers,• Use an arch tactic to make it more secure:

– Determine what is not very secure in your current project system. – Implement a tactic to improve this by a predicted amount!

• We’re also going to continue our study of how to document the arch, so:– An added feature of this project – add the functional requirements, quality attribute and

tactics sections (3 – 5) to your draft of that, for your sys.

And a first step to take today:• Try to think of a problem area in the security of your current system. (See

“characteristics of a secure system,” slide 11.)• Consult with your “implementers” to get additional ideas on problem areas. These also

will be a “target” for making changes efficiently.• Run through this area of your system as it exists now, and verify that it really is a

problem. Document that in your journal.• Make a “prediction” about how the system will be more secure, with the changes you

plan to make.• Turn in your ideas, that data on the “existing situation,” and your prediction, in your

“team journal” by tonight 11:55 PM.

Next step – Make the changes to security that will fix the problem.

6

Everyone’s interested in security

• E.g., Federal Transit Administration, part of the US Dept of Transportation:

From http://transit-safety.volpe.dot.gov/Security/SecurityInitiatives/DesignConsiderations/CD/sec9.htm.

7

What’s Bass say about this QA?

• Problem – Security is an architectural issue. If any part is not secure in some way, the whole system may be.

• Goal – Resist unauthorized usage while still providing its services to legitimate users.– Related goals like “nonrepudiation.”

• Motivation – With almost everything “online” from the WWW, they are all theoretically vulnerable.

• Scenarios – What’s in “The Notes” at the end of the supplementary spec template?

• What is Security “about” – Ch 4?• What are some good tactics – Ch 5?

8

Bass’s security scenarios

• Source: user/system, identified?• Stimulus: display info, change info,

access services, deny services• Artifact: services, data• Environment: online/offline, connected?• Response: logging, block access,

notification• Measure: time, probability of detection,

recovery

9

Example scenario

• Source: Correctly identified individual• Stimulus: Tries to modify information• Artifact: Data within the system• Environment: Under normal operations• Response: System maintains audit trail• Response Measure: Correct data is restored

within a day

10

Security situations

A runtime attribute, which might include any of these ingredients:

• Attack or threat• Confidentiality• Integrity• Assurance• Availability

Ch 4

Above - System security patent art, from www.freepatentsonline.com/6965992.html .

11

Characteristics of a secure system

• Nonrepudiation– users can’t deny they did something

• Confidentiality – No unauthorized usage

• Integrity– Data and services delivered as intended

• Assurance– Parties are who they say they are

• Availability– Denial of service attacks won’t prevent services

• Auditing– System tracks activities so that they can be reconstructed

Ch 4 – p. 86

12

Tactics to achieve security

• Try one of these 3 Strategies: – Resisting attacks– Detecting attacks– Recovering from an attack

• See next slides for details on each

Ch 5

13

Resisting Attacks

• Authenticate users– Verify who they are

• Authorize users– What can each class of users do?

• Maintain data confidentiality– Encryption, VPNs, SSLs

• Maintain integrity– Data redundancy, checksums, hash results

• Limit exposure– Allocate services to hosts so each has limits

• Limit access– Firewalls, DMZ’s

14

Detecting and Recovering

• Intrusion detection system – Anomalous patterns

• Historical baseline decides this• Filter packets according to types

– Compare with known attacks• Restoration

– See availability tactics– Restoring “state” to pre-attack is critical

• Identification– Maintain audit trail

• Trace attacker’s actions• Support nonrepudiation• Provide system recovery• Audit trails themselves are a common target!

15

Project 5 – Security part

Overall theme (of the security part of this project) – • Pick an area where you want to improve security.• Pick a strategy to improve it, using one of the above tactics, and verify

with your implementers. They may have more ideas! The improvement can be in either of these three areas:– Resisting attacks– Detecting attacks– Recovering from an attack

• You can also look ahead at Friday’s lecture for more ideas!– E.g., Check for security issues at multiple levels, default to “threat”

• Try it “as-is” to verify the security problem. Document this.• Make a “prediction” about how the system will be more secure, with

the changes you plan to make.• Make the change to improve security.• Run the security tests again, with the change. Measure how well you

achieved the goal.• Report on the results.