-A A +A

CS2013-Strawman-IAS-Information Assurance and Security (DEPRECATED)

6 posts / 0 new
Last post
sahami
CS2013-Strawman-IAS-Information Assurance and Security (DEPRECATED)

The CS2013 Strawman Report comment period is now closed. Please see the CS2013 Ironman report for the latest CS2013 draft to comment on. Forum to comment on "IAS-Information Assurance and Security" Knowledge Area in the CS2013 Strawman report. We ask that comments related to specific text in the report please specify the page number and line number(s) of the text being commented on. Line numbers are provided on the far left-hand side of the each page.

alan_fekete
Information Security
field_vote: 
0
Your rating: None

Information security is an important omission from the current draft of the curriculum. In a comment posted on Information Management (IM) chapter, I have suggested adding a section there, which should be cross-referenced to and from IAS.

bblairtaylor
First of all, great job on
field_vote: 
0
Your rating: None

First of all, great job on the document!
One comment - while secure coding and secure coding practices are addressed in several places and it is repeatedly emphasized that security is a pervasive knowledge area, I would like to see a recommendation that concepts such as best practices, secure design, and robust programming, etc., be introduced early in the course sequence, so students can learn secure programming skills from the start, rather than later, after students have established poor programming habits.

djg
Comments from Michael Hicks
field_vote: 
0
Your rating: None

[I am posting these comments on behalf of Michael Hicks from the University of Maryland and Director of the Maryland Cybersecurity Center. --Dan]

Overall I'd say IAS is a nice job, but here are some suggestions for
improvements:

line 38: should not authenticity and non-repudiation also be core terms?

line 109: HTTP --> HTTPS

lines 85 and 111: buffer overruns seem really out of place here; I
would discuss this elsewhere. These are not network security issues, but
issues with software construction that may happen to be exploited over
a network. But they could just as easily be exploited by mounting a
USB drive or typing into a local console. I also think it's odd to
focus on this particular exploit mechanism---there are other vectors
of attack that are equally important, and arguably more prevalent
today. Also, I don't see how a backdoor or trojan (mentioned on line
85) is an exploit; rather, some other exploit is usually used to
install a trojan or backdoor. Other network-based exploits are for
webapps, e.g., XSS, SQL injection, CSRF, etc. and these are worth
naming.

In general: the crypto section seems stylistically a bit sloppy, and
incomplete. I would have a look at other courses and try to match the
style and depth of content.

In particular:

lines 130-147: I find the use of "etc." jarring here: this curriculum
is meant to be complete. As such, you should list what you intend
explicitly, and not assume the reader knows what you are talking
about.

lines 150-170: I'd like to see some learning outcomes for
cryptanalysis, cryptographic algorithm design, and challenges for key
infrastructure. These are listed in the topics but absent from the
learning outcomes. There are also no applications for the outcomes;
all are indicated as "knowledge".

For the risk assessment piece: if this were an entire class it would
probably be pretty abstract, and might be quite boring for it. I
think the material is important, but it's critical to ground it in actual
IAS topics. I'd like to see some of these listed in the curriculum.
Alternatively, you could also apply risk assessment to software
engineering generally, with respect to design, construction, and
maintenance (e.g., bug handling) of a software system. Then you could
use security and reliability as examples.

For the IAS/Security policy and governance piece: will you also
consider practical/legal policies, such as HIPAA and Sarbanes-Oxley?
Also, the Windows 7 integrity policies (not quite Biba) and varieties
in between would be useful. This material seems quite appropriate for
IAS/Security Architecture and Systems Administration, which already
covers access control. Since the latter policy is often quite
limiting, exploring alternative policies (and real-world
implementations) would be really good. If this makes sense, perhaps
this Knowledge Unit ends up sparse and isn't needed.

For forensics: this looks pretty good. But I think the topics
description could be much better. Instead of saying OS, mobile,
device, etc., I think we should be more interested in goals,
techniques, and pitfalls of extracting information, generally. Then
we can look at particular platforms. What are general concepts that
cross different platforms (e.g., filesystem analysis, or cold storage
analysis)? I think it would be good to name those explicitly.

The architecture section looks good. I would suggest you also include
the concept of "attack surface" when talking about assessing system
vulnerabilities.

Nits:

line 6: authentication --> authenticity

lines 8-9: The statement "Both assurance and security concepts are
needed to ensure a complete perspective" is not crisp because these
two concepts are not defined separately in the preceding text, but are
rather defined together, without distinction.

line 11: attest to the assurance of the past and current state -->
attest to authenticity of the past and current state

lines 13-23 can be trimmed: these lines appear to make the same point
three times, which is that some topics of IAS are pervasive throughout
the other KAs and some are presented here

dcdl
Feedback on KA: IAS- Information Assurance and Security
field_vote: 
0
Your rating: None

I have posted some comments that I believe apply to all KAs within the CS2013 Strawman Report-Chapters 1-5 thread. I would like to make reference to those comments here since they apply to all KAs.

The comments are posted under the following subjects:
First of All: Thank You.
Matching of Topics and Learning Outcomes for Core-Tier-1 and 2.
Unique Labeling or Numbering of all Topics and Learning Outcomes.
Improved Correspondence between Learning Outcomes and Topics.
Consistent Labeling for Levels of Understanding.
On the Importance of the Learning Outcomes in Core-Tier1 and 2.

Comments for this KA:

Page 76, Lines 4-8: I think a clearer set of sentences with the same meaning would read something like this:

Information assurance and security as a knowledge area corresponds to the set of processes, tools, and controls, technical and organizational, intended to protect and defend information and computer systems. It is accomplished by ensuring the required confidentiality, integrity, and availability of information and systems and their associated infrastructure, ensuring that only authorized parties have access to protected information and systems, providing for non-repudiation, and avoiding unauthorized, unintended, or malicious access, disclosure, or modification to data and unauthorized, unintended, or malicious access or damage to systems and their infrastructure. The concept of information assurance also carries a well-founded attestation that current and past data is authentic and correct and that systems and processes are adequate and valid with respect to their intended purposes.

Page 76, Line 17: where it says 'core (tier1and tier2)' it should say Core (Tier1 and Tier2).

Page 79, Lines 36: I would write: Modern society dependence on information systems, nature of the current threats and past and potential attacks and their consequences.

Page 79, Lines 36: I would write: The need for Information Assurance and Secure Systems in all modern organizations and why it is relevant to all CS majors.

Page 79, Lines 38-39: Basic terminology: Confidentiality, Integrity, Availability, Authorization and Authentication, Accountability and Non-repudiation, Anonymity and Privacy, and Assurance.

Page 79, Line 40: I would rite: 'Information assurance and security principles. For example. Saltzer and Schroeder's 10 security principles.'

Page 79, Line 44: I would write: 'Legal and cultural differences between nations and states, such as different privacy protection laws.' and as separate topic before: Applicable laws and regulations. For example, HIPPA and Sarbanes-Oxley in the U.S.A. And similar laws in other conutries, the Data Protection Directive in the E.U., and Copyright and Intellectual Property (IP) laws.

Page 79, Line 45: Please indicate if the hours are to be counted within the IAS KA or within the SP KA.

Page 79, Line 49: I would write 'Introduction to approaches, techniques, and processes used in Information Assurance and Security'. (described by the other KUs).

Page 79, Line 50: I would write 'Introduction to Incidents and incident response policies and mechanisms' .

Page 80, Line 55: I believe that the question mark is not needed.

Page 80, Line 78: Still mostly known as SSL. In my opinion it should say 'Secure sockets (SSL and TLS)'. I would mode this to the Core-Tier2 section. I believe that the other topics already account for 1 or more hours.

Page 80, Line 79: I would add '(Symmetric)'.

Page 80, Line 80: I would add '(Asymmetric)'.

Page 80, Line 81: I would write 'Hybrid or combined uses of encryption'.

Page 80, Line 82: I would add: 'Applications such as SSH and SSL/TLS'.

Page 80, Line 90: I would write 'Intrusion prevention'; Intrusion detection is a detection only mechanism not a prevention mechanism. In addition, I would probably separate this into more than one subtopic, and remove NAT since it is not per-se a security technique but a network addressing technique that should be listed within the NC KA.

Page 80, Line 92: I would put 'Network Accountability and Auditing.' as Elective within this KU.

Page 80, Line 94 - 125: There are several learning outcomes in this KU (IAS/Network Security) that would, in my opinion, correspond within other KUs. For example, identifying and correcting buffer-overflows should appear in the IAS/Secure Software Design and Engineering KU.

Page 81, Line 102: I would say: 'Describe how hybrid encryption schemes may be used in SSL/TLS.'

Page 81, Lines 102 and 105: I would say: 'Describe how encryption is used ...'. not necessarily public key but also private key.

Page 81, Line 102: I would add: 'Describe how SSL and TLS can be used to encrypt HTTP traffic (HTTPS)'.

Page 81, Line 108: Appears to be a sentence fragment.

Page 81, Line 111 and 112: I believe that the learning outcomes of identifying and correcting buffer-overflows should appear in the IAS/Secure Software Design and Engineering KU; therefore not here.

Page 81, Line 119: better to use the word 'stateless' rather than 'non-stateful'.

Page 81, Line 120: I would say 'configure' rather than 'implement'.

Page 81, Line 127: I would say 'security techniques' rather than 'approaches to security'.

Page 81, Line 143: I would say 'SHA (all)' rather than 'SHA-1'.

Page 82, Line 189: Appears to be a sentence fragment.

Page 83, Line 210: I would add: 'Define Mitigation and Describe Mitigation Techniques [Knowledge]'.

Page 85, Line 275-276: It should say 'tamper-resistant' rather than 'tamper-resistance'.

Page 85, Line 279: Sentence is not clear. In addition it should include 'unintended'.

Page 85, Line 280-281: It should say: Physical Access Control as a determinant of who, when, and where is allowed to traverse a physical security perimeter (enter or exit).

Page 85, Line 288: I would separate 'Multilevel security' from 'Multilateral security' into their own topic lines.

Page 85, Line 293: 'SCADA System uses' should be moved to the topic in line 292.

Page 85, Line 295: I would write 'Implementation of Data and Communications Integrity in the Organization' to differentiate form the basic integrity concept which is listed as a topic in IAS/Fundamental Concepts.

Page 85, Line 296: I would write 'Implementation of Data and Communications Confidentiality in the Organization' to differentiate form the basic confidentiality concept which is listed as a topic in IAS/Fundamental Concepts.

Page 86, Line 333: What do we mean by Data validation?

Page 86, Line 347: In would argue that this topic is not a learning outcome. Otherwise, I would like to be pointed to scientific studies that have identified significant differences with respect to security. I think it is important to discuss the issue in order to show the absence of scientifically based conclusions in the issue.

Page 86, Line 357: There are many places that need some editing. For example, in page 86, Line 357 ' What do we mean by Data validation?' is a written as a question not as a learning outcome.

sahami
Additional comments (received via email)
field_vote: 
0
Your rating: None

A number of aspects of this knowledge area merit comment: there are several typographical matters.

Books should not be referred to explicitly as they are in certain parts of this, e.g. Secure Software Design and Engineering.

See page 29. IAS is also about protecting people, organisations, etc. The systems dimension of security might come through more strongly.

Learning outcomes

Some of the learning outcomes are phrased as questions, which they should not be. Reduce dramatically the number of learning outcomes, pitching them at a higher level of abstraction.

The number of learning outcomes associated with many topic areas is enormous, e.g. 28. Moreover the 28 do not seem to be structured in any obvious way. Correspondingly it is not easy to tell whether there should be 29 or 27 or whatever. I might have expected a more systematic approach and therefore a structure for all learning outcomes, e.g. taking the form: basic definitions, theories underpinning this area, algorithmic issues, techniques, practices. In this way there would naturally be a range of outcomes – not all discuss or describe for instance. Also omissions / overlaps would be more evident.

With these structuring thoughts in mind I would also tend to reorganise the sub-topics within the IAS area.

Risk

In risk management there are traditionally (at least) three different kinds of risk: organisational risk, project risk and technical risk. In the report the emphasis is on organisational risk whereas I would have expected it to be on technical risk. By that I mean choice of languages, choice of techniques, approaches to testing and verification, and so on.

So I might have expected something like:

• Definition of important terms such as risk, hazard. The special problem of risk in the context of security.
• Methods for identifying the hazards in a given system: list various commonly used possibilities
• Quantification of risk: individual risk, system risk. Differing levels of integrity of systems.
• Risk management: risk removal, risk reduction, risk control. Approaches to achieving these.
• Hazards and risks in the context of building safe / secure computer systems.

And so on.

Additional matters

Theoretical considerations, e.g. is it possible to have an algorithm to make all systems secure?

Cross-site scripting and other ways of compromising security on web based systems.

What are the special problems of mobility and wireless in relation to security?

Economics of security.

Industrial standards – their role here, like Owasp.

Log in or register to post comments