Information Security and Security Architecture

Size: px
Start display at page:

Download "Information Security and Security Architecture"

Transcription

1 Information Security and Security Architecture (Informasjonssikkerhet og sikkerhetsarkitektur) Stephen D. Wolthusen Department of Computer Science Gjøvik University College October 25, 2007 / Session 5 Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 1 / 155

2 Outline 1 Lecture Overview 2 Vulnerabilities and Attack Techniques 3 Evaluation Criteria: Introduction 4 Origins of Evaluation Criteria 5 TCSEC 6 Other National Criteria and ITSEC 7 CCITSE 8 Malware 9 Summary Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 2 / 155

3 Outline 1 Lecture Overview 2 Vulnerabilities and Attack Techniques 3 Evaluation Criteria: Introduction 4 Origins of Evaluation Criteria 5 TCSEC 6 Other National Criteria and ITSEC 7 CCITSE 8 Malware 9 Summary Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 3 / 155

4 Session 5 (today) Vulnerabilities and Attack Techniques Buffer Overruns and Defenses Input Validation and Injection Attacks Race Conditions Evaluation Criteria Origins of Evaluation Criteria TCSEC, NATO, UK, French, German National Criteria European ITSEC Criteria Common Criteria for Information Technology Security Evaluation Malware Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 4 / 155

5 Outline 1 Lecture Overview 2 Vulnerabilities and Attack Techniques 3 Evaluation Criteria: Introduction 4 Origins of Evaluation Criteria 5 TCSEC 6 Other National Criteria and ITSEC 7 CCITSE 8 Malware 9 Summary Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 5 / 155

6 Definitions As usual, we begin with a few definitions of key terms: Asset Resources contributing to an organization s capability for fulfilling its mission Vulnerability Weaknessess of assets that, if exploited, devalue the asset Threat Any circumstance or event that has the potential to cause harm to assets Exploit Attack on assets taking advantage of one or more vulnerabilities Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 6 / 155

7 Typical Attack Objectives Denial of service Withhold timely use of assets from legitimate users This problem does not need not be caused by vulnerabilities Privilege escalation Obtain access rights beyond those privileges assigned to the currently active entity Impersonation Obtain identity or access privileges of another entity (usually with higher privileges) Can also be considered a variant of privilege escalation Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 7 / 155

8 Common Vulnerabilities Faulty environmental assumptions Systems operating outside design parameters Configuration flaws Misconfigured security mechanisms Use of services unsuitable for threat environment Implementation flaws Input validation Logical flaws Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 8 / 155

9 Locality of Exploitability Severity of exploits is co-determined by its feasibility. This is influenced significantly by the requisite proximity and privileges: Physical access Attackers must have direct physical access to targeted devices. Access may be at several levels depending on conspicuousness of attacks and device location Local exploit Attackers must have obtained existing privileges on the target, the actual access can occur either with physical access or via an authorized access network path Remote exploit No prerequisites other than provision of some (faulty or misconfigured) network service is required for this the most severe type of attack Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 9 / 155

10 Exploitability Parameters Credentials Exploits for which credentials must be obtained are typically privilege escalation attacks, DoS attacks are trivial on most systems once credentials are available Without credentials, the exploit must modify an existing execution path to perform desired actions, including for obtaining credentials (often shellcode ) Social engineering (phishing, etc.) for obtaining credentials is quite common, but here we are concerned only with technical exploits Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 10 / 155

11 Common Vulnerabilities: Buffer Overflows Overwriting memory locations beyond their intended capacity can result in changes in control flow or other exploitable behavior Problem has been known as a security vulnerability for more than 30 years... but still the majority of published exploits are based on some form of buffer overflow Primary problem: Inappropriate choice of tools (programming languages) Most operating systems are written in C/C++, the same also holds for most system libraries and application software C/C++ leave memory management to programmers, do not provide bounds checking Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 11 / 155

12 Typical Stack Layout of x86 Unixoid Systems Kernel Stack (per process) Higher addresses Red Zone u Area ps_strings struct signal-code env-strings argv-strings env-pointer Command line arguments and shell environment argv-pointer argc User-Stack Heap BSS Symbol table DATA DATA TEXT TEXT Process in memory Linker header, Magic number Executable file (ELF) Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 12 / 155

13 Stack Frame Operation (Unix x86) void foo(int a, int b, int c) { char bar[5]; char baz[5]; } int main(void) { foo(1,2,3); return 0; 10 } Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 13 / 155

14 Stack Frame Operation (Unix x86) argc High addresses User-Stack c b a Return address Frame pointer bar baz Heap BSS Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 13 / 155

15 Stack Frame Operation (Unix x86) Assembly for code for pushing arguments onto the stack in reverse : pushl $1 pushl $2 pushl $3 Compiler-generated code for creating stack frame: pushl movl subl %ebp %esp,%ebp $20,%esp Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 13 / 155

16 Stack Overflow (Unix x86) void foobar(char *s) { char badzoing[16]; strcpy(badzoing,s); } int main(void) { char bazooka[256]; int i; 10 for(i=0; i<256; i++) bazooka[i]=42; foobar(bazooka); return 0; } Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 14 / 155

17 Stack Overflow (Unix x86) argc High addresses argc User-Stack s Return address Frame pointer User-Stack s Return address Frame pointer badzoing badzoing Heap BSS Heap BSS Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 14 / 155

18 Shell Code Insertion In the simplest variant, the return address on the stack is overwritten with an address of the attacker s own code Permits the execution of arbitrary (small) code segments Typically this is shellcode, yielding a (privileged) shell for the attacker: execve(whatever,"/bin/sh",null) suffices Optimized shellcodes for various operating systems and processor archtiectures are available widely (via Phrack, etc.) Main issue here is calibrating the buffer overflow properly so it will hit the return address precisely (the shellcode can be padded out with NOP operations or can be replicated in multiple places) Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 15 / 155

19 Defensive Measures Against Stack Overflows (1) Non-Executable Stack Making the stack memory pages non-executable makes placement of the attacker s code on the stack harmless This technique typically requires hardware support to be efficient; most modern processors support this (e.g. Sun Solaris on UltraSPARC since 1996, Intel XD, AMD NX) Can be circumvented: Executable code can still be injected if other data areas are executable More elegant circumvention method: Return into libc Modify return address to point into system code, preferably a library with known addresses Return jumps to system(1) (direct or through calls elsewhere in libraries) provide equivalent to shellcode, desired arguments can still be put on stack Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 16 / 155

20 Defensive Measures Against Stack Overflows (2) Defenses against the return into libc-style attack: Randomization of library base addresses: Since libraries are linked dynamically, these can be permuted randomly and re-based in virtual memory PaX (Page EXec) provides this as a proof-of-concept for the Linux kernel, but requires all applications to be re-linked along with a page fault hook for identifying execution of data segments Workarounds (hacks) exist to circumvent PaX, but are somewhat difficult to write since they are in part based on heuristics to find out randomized addresses Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 17 / 155

21 Defensive Measures Against Stack Overflows (3) StackGuard (Cowan 1998) A canary value is placed between frame and instruction pointers and function arguments during the function prologue and is validated during function epilogue Modified canary values lead to calling a handler that can terminate the offending program Several variants have been proposed including terminator values, random values, and random XOR values SSP (Etoh 2003) Reorders arguments on the stack, placing pointers higher on the stack than buffers Copies function arguments to local stack frame, protecting handler Frame pointers must be protected in either case to prevent reordering of stack frame Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 18 / 155

22 Heap Overflows Exploits relying on similar weaknesses as stack overflows (lack of type checking, array bounds checking, etc.) Structures for managing heap are typically placed in the heap as well Most common approach is to maintain a linked list of memory blocks that can be split and coalesced as necessary Overwriting the bounds of one s own buffer (list element) allows writing into buffers and variables behind, modifying program behavior or even inserting code Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 19 / 155

23 Protection Against Heap Overflows Microsoft XP SP2 Heap Protection Variant on the canary method using cookies and sanity checks on the integrity of the heap doubly-linked-list chaining properties PointGuard (Cowan 2003) Usable for both stack and heap protection, for heap protection requires that libc is compiled with PointGuard Encrypts pointer values in memory by XORing it with a random value derived at runtime Pointers are decrypted only in registers Can be defeated using format string attacks Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 20 / 155

24 Input Validation (1) Format String Attacks Can be considered a variant of buffer overflow attacks but also as an input validation error Typically associated with libc-style format strings (printf(1), scanf(1), etc.) Buffers may be too small or of fixed size without limiting input correspondingly Effects can also occur through injection of format strings (e.g. %s) in secondary strings that will then get interpreted again Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 21 / 155

25 Other Low-Level Targets Function Pointer Manipulation A feature in C/C++ and in hidden form also in some other object-oriented languages: function pointers, vtables, etc. Overwriting a function pointer permits calls to arbitrary locations, altough not with attacker-selected arguments Longjmp buffers A C artifact permitting stack unrolling and jumps to arbitrary locations (potentially dangerous even for legitimate programs) Longjmp stores the current location in a buffer, which can be stored anywhere (just like function pointers), and can be corrupted using the usual heap and stack overwriting techniques Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 22 / 155

26 Input Validation (2) A similar problem to format strings (interpreting maliciously inserted code, not checking the wrapping of command input) also occurs in database systems: SQL injection Particularly for web and intranet applications, input strings are frequently passed on to database subsystems With the proper escape sequences in the string, these can be interpreted as part of the code, not just the data Can wreak havoc in data tables (electronic commerce systems, etc.) but also to execute shell commands Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 23 / 155

27 SQL Injection Attacks: Example (1) Suppose an application contains the following code processing form data: SELECT fieldlist FROM table WHERE field = $ ; In some locations (e.g. WHERE clauses), unbalanced escapes can escape: SELECT , passwd, login id, full name FROM members WHERE = AND passwd = badzoing ; This permits the insertion of additional code: SELECT fieldlist FROM table WHERE field = foo OR x = x ; Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 24 / 155

28 SQL Injection Attacks: Example (2) That still leaves several problems open, primarily identifying field and table names. Guessing might work like this (note comment at end): SELECT fieldlist FROM table WHERE field = XXX AND IS NULL; ; For table names, guesses for tabname can be verified: SELECT , passwd, login_id, full_name FROM table WHERE = x AND 1=(SELECT COUNT(*) FROM tabname); If a field is not a member of the current WITH statement, this too needs to be guessed: SELECT , passwd, login_id, full_name FROM members WHERE = x AND members. IS NULL; ; Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 25 / 155

29 SQL Injection Attacks: Example (3) This now permits reading out database fields (e.g. through error messages) or, if tables are not write-protected the insertion or deletion of arbitrary records in the database: SELECT , passwd, login_id, full_name FROM members WHERE = x ; DROP TABLE members; ; This type of attack is difficult to detect at the network (firewall, IDS) level, since these are nominally legitimate communications with protected servers Other attack venues: Stored Procedures Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 26 / 155

30 Script Code Injection Defensive measures: Principle of least privilege (for processes serving databases, access rights to database, use of restricted views) Input validation and normalization This may often mean having to parse input first Similar problems occur in other scripting language settings (e.g. PHP, Perl) or wherever input data may be parsed dynamically Perl taint mechanism Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 27 / 155

31 Input Validation (3) Input validation may also have to occur multiple times Input re-interpretation Example: Microsoft IIS Unicode homophone attack: The.. -Attack was used during the NCSA httpd time to traverse disallowed directory structures Microsoft IIS did check for.. path elements, but... someone (unnecessarily) decided to support Unicode for inputs such as HTTP GET requests Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 28 / 155

32 Input Validation (4): IIS Unicode Injection Checking for.. path elements and other undesirable elements was done on the original input Unicode translation and normalization occurred after this initial check Encoding (parts) of malicious commands in Unicode representation allowed bypassing this check Actual execution occurred over the normalized code Similar bypasses can also occur in other application domains, e.g. for web services Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 29 / 155

33 Link Attacks (1) File system links: Hard links Windows: CreateHardLink somewhat obscure Unix link(2) Soft links Windows: Reparse points or directory junctions, subst from old DOS days Drive letter substitution is often used as a crutch to circumvent path size limit (256 characters) Substitutions can persist across sessions, users may unwittingly use arbitrary directories of someone else s choosing Unix link(2) Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 30 / 155

34 Link Attacks (2) Hard links Creation is limited to files (no directories allowed) Can only be created within one file system Indistinguishable the file system level from the original file Files get deleted only if link and reference count reaches 0 Support for hard links is file system dependent (for both Windows and Unix) Hard links can be useful for attackers wishing to confuse audit trails (file access logging will record only benign path, not the hard-linked file) Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 31 / 155

35 Link Attacks (3) Soft (symbolic) links Windows soft links (reparse points) are limited to directories, design intention was more to emulate mount points than soft links Unix soft links can be considered as special text files containing path data that are interpreted on access These can refer to files and directories and may also span file systems Permissions on soft links are different from source file Removal of symbolic link does not affect source file, source file need not exist at symbolic link creation Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 32 / 155

36 Link Attacks (3) Soft link attacks occur when the attacker can link to a (sensitive) file and get a privileged process to operate on the symbolic link as desired Typically an attacker will have to substitute a file that the privileged process would normally access Attacker must have write access to one of these directories for link creation: Such attacks often involve shared (e.g. /tmp) directories One of the most common and long-running source of local exploits on Unix and unixoid systems Countermeasures should typically include sanity checks for permissions and in some cases the use of symbolic links may need to be prohibited Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 33 / 155

37 Race Conditions and TOCTOU Originally from electronics: Two signals racing to influence an output signal first In computing, simultaneous resource contention for variables, files, network access Commonly addressed with mutexes, semaphores or lock files Frequent venue for attacks, primarily local The Time-of-Check-to-Time-of-Use (TOCTOU) problem Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 34 / 155

38 Race Condition Example (1) Consider a Unix system with two active users: 1 User A creates a file X with world-writable umask 2 User A changes permissions to a more secure configuration for X 3 User B writes into X The process of file creation with secure permissions is not atomic, the sequence above can be 1,2,3 or 1,3,2 depending on the pre-emption characteristics of the operating system Common problem in database systems if locks are not used carefully Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 35 / 155

39 Whenever there is a simple error that most laymen fall for, there is always a slightly more sophisticated version of the same problem that experts fall for. Amos Tversky Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 36 / 155

40 Follow-Up Attack Measures Once an attacker has gained a foothold in a system, he must try to avoid detection by IDS/IPS systems and system administrators. For this, root kits are often used Collection of tools and utilities allowing an attacker to hide his presence and communication from users and administrators, it may also allow the attacker to gather information for further attacks Strategies include modified command binaries, inserting kernel modules, modifying kernel data structures and system/library call interfaces Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 37 / 155

41 Defensive Development Measures (1) Buffer overflows and injection attacks can both be (largely) avoided if adequate development methods are used. These include: Testing strategies Black-box testing Targeted manual search for vulnerabilities Unit testing using boundary cases Fuzzing Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 38 / 155

42 Defensive Development Measures (2) A number of automated tools can help to identify some problems. A class that has made many advances in recent years is the static analysis approach. Some tools include: FlawFinder for C/C++ (Wheeler, 2001ff) RATS (Rough Auditing Tool for Security) for C/C++, PHP, and Python programs ITS4 (It s the Software Stupid Source Scanner) for C/C++ (Cigital) PreFix/PreFast (Microsoft) Splint (Secure Programming Lint) for C (Evans, 1994ff) Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 39 / 155

43 Defensive Development Measures (3) Model Checking Creates a finite state machine from the system specification and checks whether desirable properties hold Several types of checks are commonly identified: Reachability analysis (application independent) Behavioral model checking (application dependent control properties) Relational model checking (application dependent data properties) But: Requires a formalized and well-defined specification, challenge of combinatorial explosion Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 40 / 155

44 Full Disclosure (1) A discussion that is at least as old as the BUGTRAQ mailing list (1993): If information sufficient to reproduce a vulnerability is disclosed, then attackers (including less capable ones) will be aided But: Lack of disclosure makes it easier for vendors to delay remedies and ignore problems Full disclosure often is accompanied by example or proof of concept code Typically does not contain malicious payload or all steps necessary to conduct real-world attack But: This can often be transformed trivially into a full attack Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 41 / 155

45 Full Disclosure (2) Changes in motivations for publication of vulnerabilities: Individuals sought recognition, intellectual challenges, sometimes wanted to shame vendors into doing the right thing Vendors occasionally may take several months or more to address a vulnerability disclosure can also be a result of frustration In recent years it is often (small) consulting firms that publish vulnerabilities, even if discovered elsewhere Increasing a company s reputation and thereby revenue Boderline with extortion occasionally becomes blurred both ways Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 42 / 155

46 Full Disclosure (3) Restricting full disclosure? Disclosure will usually result in removal of defects Non-disclosure does not keep others from identifying the same or similar flaws: Potential for lengthening the period of (undetected) use of a vulnerability for attacks But: It is unlikely that another attacker would identify precisely the same flaw, so a comparison of the relative impact is not always feasible Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 43 / 155

47 Full Disclosure (3) Legal issues and full disclosure: The WIPO (World Intellectual Property Rights Organization) WCT (WIPO Copyright Treaty) and its national implementations such as the U.S. DMCA, the EU Copyright Directive, and Norwegian national legislation can make disclosure of vulnerability information or circumvention of controls for protected systems illegal There have been threats and arrests based on this legislation, particularly in the US Threat of lawsuit under DMCA (HP vs. SnoSoft, 2002) Arrest of D. Skylarov following complaint of Adobe against ElcomSoft (2001) Cybercrime Convention of the Council of Europe (Norway is a member!) may make it illegal to possess typical proof-of-concept code Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 44 / 155

48 Outline 1 Lecture Overview 2 Vulnerabilities and Attack Techniques 3 Evaluation Criteria: Introduction 4 Origins of Evaluation Criteria 5 TCSEC 6 Other National Criteria and ITSEC 7 CCITSE 8 Malware 9 Summary Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 45 / 155

49 Assurance Terminology Trust The belief that a entity will behave in a predictable (typically benign or beneficial) manner Trustworthiness A measure of how extensively a given entity deserves to be trusted to satisfy its stated requirements when confronted with arbitrary threats Assurance The level of certainty to which assertions about entity behavior can be believed or proven Here we limit assurance to its security-related aspects only: Definition Assurance is defined as the grounds for confidence that a given information system meets the explicitly defined security properties Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 46 / 155

50 What Can Go Wrong in Creating Secure Systems Requirements: Definition, omissions, and errors System design flaws Hardware implementation flaws Software implementation flaws Operator errors, system misuse (deliberate or inadvertent) Targeted misuse, exploitation Transient malfunctions (e.g. hardware faults) Environment outside the information system Flaws introduced during maintenance and upgrades... and most importantly: Things you did not think about Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 47 / 155

51 Evaluation Processes The primary motivation for conducting evaluation is to provide reliable and reproducible means of creating assurances Vendor claims may not be substantiated or be backed up by appropriate warranties and liabilities In-house testing and evaluation by a user may not be feasible for cost reasons and because the necessary background and knowledge Evaluations by a knowledgeable third party can be a viable alternative, if The third party is impartial and objective Requirements of users can be captured adequately and with sufficient precision The evaluation results are reliable and reproducible Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 48 / 155

52 Requirements For a system or component overall security objectives must be formulated which then can be refined: External factors (e.g. system operating environment, threat profiles) and assumptions must be formulated and clarified Security requirements address specific system components and their operation These requirements are typically shaped and constrained by the external factors and assumptions identified before Refinement of requirements must usually occur in several steps At any stage in the requirement refinement process inconsistencies and contradictions may arise, the requirements process must monitor and address such conflicts Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 49 / 155

53 Assurance Elements (1) Determining conformance of an artifact with a set of objectives and requirements is usually not feasible in one step. Divide assurance into several steps: Definition (Policy Assurance) Policy assurance is the evidence establishing that the set of security requirements in the policy is complete, consistent, and technically sound. This evidence is arrived at based on an analysis of the requirements based on the security threats and objectives identified before Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 50 / 155

54 Assurance Elements (2) The next step in the inductive derivation of a secure system establishes the necessity and sufficiency of the system design: Definition (Design Assurance) Design assurance is the evidence establishing that a design is sufficient to meet the requirements of the policy. This is followed by arguments or proofs establishing the consistency of an implementation with the design: Definition (Implementation Assurance) Implementation assurance is the evidence establishing that an implementation of a given design is consistent with the requirements of the policy. Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 51 / 155

55 Assurance Elements (3) To ensure compliance with the assumptions and external factors identified in the policy, an additional element of assurance is finally required for the actual operation of a system: Definition (Administrative Assurance) Administrative assurance is the evidence establishing that the system sustains the policy requirements during installation, configuration, and operation. This establishes (linear) procedures and requirements for secure systems. In most cases, this is insufficient: Systems frequently have a pronounced life cycle: More on this in the next session Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 52 / 155

56 Assurance Model Overview may may Evaluation assurance promote Developmental assurance promote Other assurances use of use of Evaluation validates may provide increases in Application of security engineering techniques and processes which produce may indicate use of Examples: Vendor assertions, track record of vendor, warranty, liability insurance of vendor... validates Security quality which implies Stakeholders who require which support Confidence which instill Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 53 / 155

57 Outline 1 Lecture Overview 2 Vulnerabilities and Attack Techniques 3 Evaluation Criteria: Introduction 4 Origins of Evaluation Criteria 5 TCSEC 6 Other National Criteria and ITSEC 7 CCITSE 8 Malware 9 Summary Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 54 / 155

58 Origins of Evaluation Criteria During the mid-late 1970s the U.S. Department of Defense was looking for a mechanism to improve the security, quality, and assurance of its information systems U.S. Defense Science Board formed a task force investigating requirements in parallel to creating the DoD Computer Security Initiative (1977) Based on requirements and studies primarily conducted by the U.S. Air Force, MITRE issued a study in 1979 proposing seven levels of protection and evaluation factors for these levels Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 55 / 155

59 Objectives of 1979 MITRE Report The report considered the elements policy, mechanisms, and assurance and identified the following objectives: Identification of security aspects and mechanisms of operating systems (including arguments for necessity and sufficiency) Prioritization of operating system security mechanisms Classification of security mechanism complexes into levels of protection/security Note that this report did not look at environmental requirements and assumptions in detail and assumed a single non-networked computer system as its target. Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 56 / 155

60 Levels of Protection in the MITRE Report (1) The MITRE report classified compliance with the DoD confidentialty requirements into 7 levels. These levels formed a hierarchy with higher-level systems providing all protection and security features of lower levels: Level 0 No basis for confidence in the system s ability to protect information Level 1 Some attempt to control access is given, but only limited confidence in viability of the security controls is indicated Level 2 Meets minimal requirements of security policy with assurance derived primarily from information on design and testing Stephen D. Wolthusen (NISlab) IMT 4161 Session 4 57 / 155

System Assurance C H A P T E R 12

System Assurance C H A P T E R 12 C H A P T E R 12 System Assurance 169 The aim of system assurance is to verify that a system enforces a desired set of security goals. For example, we would like to know that a new operating system that

More information

Constructing Trusted Code Base XIV

Constructing Trusted Code Base XIV Constructing Trusted Code Base XIV Certification Aleksy Schubert & Jacek Chrząszcz Today s news (on tvn24bis.pl) (June 6th on BBC) security vulnerability CVE-2014-0224 was discovered by Masashi Kikuchi

More information

CMSC 421, Operating Systems. Fall 2008. Security. URL: http://www.csee.umbc.edu/~kalpakis/courses/421. Dr. Kalpakis

CMSC 421, Operating Systems. Fall 2008. Security. URL: http://www.csee.umbc.edu/~kalpakis/courses/421. Dr. Kalpakis CMSC 421, Operating Systems. Fall 2008 Security Dr. Kalpakis URL: http://www.csee.umbc.edu/~kalpakis/courses/421 Outline The Security Problem Authentication Program Threats System Threats Securing Systems

More information

Information Technology Security Evaluation Criteria. ITSEC Joint Interpretation Library (ITSEC JIL)

Information Technology Security Evaluation Criteria. ITSEC Joint Interpretation Library (ITSEC JIL) S Information Technology Security Evaluation Criteria ITSEC Joint Interpretation Library (ITSEC JIL) Version 2.0 November 1998 This document is paginated from i to vi and from 1 to 65 ITSEC Joint Interpretation

More information

Computer Security. Evaluation Methodology CIS 5370. Value of Independent Analysis. Evaluating Systems Chapter 21

Computer Security. Evaluation Methodology CIS 5370. Value of Independent Analysis. Evaluating Systems Chapter 21 Computer Security CIS 5370 Evaluating Systems Chapter 21 1 Evaluation Methodology 1. Set of security functionality requirements 2. Set of assurance a requirements e e 3. Methodology to determine if the

More information

Plain English Guide To Common Criteria Requirements In The. Field Device Protection Profile Version 0.75

Plain English Guide To Common Criteria Requirements In The. Field Device Protection Profile Version 0.75 Plain English Guide To Common Criteria Requirements In The Field Device Protection Profile Version 0.75 Prepared For: Process Control Security Requirements Forum (PCSRF) Prepared By: Digital Bond, Inc.

More information

Unix Security Technologies. Pete Markowsky

Unix Security Technologies. Pete Markowsky <peterm[at] ccs.neu.edu> Unix Security Technologies Pete Markowsky What is this about? The goal of this CPU/SWS are: Introduce you to classic vulnerabilities Get you to understand security advisories Make

More information

X05. An Overview of Source Code Scanning Tools. Loulwa Salem. Las Vegas, NV. IBM Corporation 2006. IBM System p, AIX 5L & Linux Technical University

X05. An Overview of Source Code Scanning Tools. Loulwa Salem. Las Vegas, NV. IBM Corporation 2006. IBM System p, AIX 5L & Linux Technical University X05 An Overview of Source Code Scanning Tools Loulwa Salem Las Vegas, NV Objectives This session will introduce better coding practices and tools available to aid developers in producing more secure code.

More information

Certification Report

Certification Report Certification Report EAL 2+ Evaluation of Issued by: Communications Security Establishment Certification Body Canadian Common Criteria Evaluation and Certification Scheme 2008 Government of Canada, Communications

More information

Access Control Fundamentals

Access Control Fundamentals C H A P T E R 2 Access Control Fundamentals An access enforcement mechanism authorizes requests (e.g., system calls) from multiple subjects (e.g., users, processes, etc.) to perform operations (e.g., read,,

More information

83-10-35 A New Security Model for Networks and the Internet Dan Thomsen Payoff

83-10-35 A New Security Model for Networks and the Internet Dan Thomsen Payoff 83-10-35 A New Security Model for Networks and the Internet Dan Thomsen Payoff Computer security is a matter of controlling how data is shared for reading and modifying. Type enforcement is a new security

More information

Secure Web Application Coding Team Introductory Meeting December 1, 2005 1:00 2:00PM Bits & Pieces Room, Sansom West Room 306 Agenda

Secure Web Application Coding Team Introductory Meeting December 1, 2005 1:00 2:00PM Bits & Pieces Room, Sansom West Room 306 Agenda Secure Web Application Coding Team Introductory Meeting December 1, 2005 1:00 2:00PM Bits & Pieces Room, Sansom West Room 306 Agenda 1. Introductions for new members (5 minutes) 2. Name of group 3. Current

More information

Software Vulnerabilities

Software Vulnerabilities Software Vulnerabilities -- stack overflow Code based security Code based security discusses typical vulnerabilities made by programmers that can be exploited by miscreants Implementing safe software in

More information

CIS 551 / TCOM 401 Computer and Network Security. Spring 2007 Lecture 6

CIS 551 / TCOM 401 Computer and Network Security. Spring 2007 Lecture 6 CIS 551 / TCOM 401 Computer and Network Security Spring 2007 Lecture 6 Announcements Reminder: Send in project groups TODAY If you don't have a group, let us know. If you haven't started on the project

More information

Certification Report

Certification Report Certification Report EAL 4+ Evaluation of Solaris 10 Release 11/06 Trusted Extensions Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria Evaluation and

More information

Certification Report

Certification Report Certification Report EAL 4+ Evaluation of Netezza Performance Server v4.6.5 Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria Evaluation and Certification

More information

What is Web Security? Motivation

What is Web Security? Motivation brucker@inf.ethz.ch http://www.brucker.ch/ Information Security ETH Zürich Zürich, Switzerland Information Security Fundamentals March 23, 2004 The End Users View The Server Providers View What is Web

More information

Certification Report

Certification Report Certification Report EAL 2+ Evaluation of Symantec Endpoint Protection Version 12.1.2 Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria Evaluation and

More information

Certification Report

Certification Report Certification Report EAL 4+ Evaluation of BlackBerry Enterprise Server version 5.0.0 Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria Evaluation and Certification

More information

CIS 551 / TCOM 401 Computer and Network Security. Spring 2006 Lecture 7

CIS 551 / TCOM 401 Computer and Network Security. Spring 2006 Lecture 7 CIS 551 / TCOM 401 Computer and Network Security Spring 2006 Lecture 7 Announcements Reminder: First Midterm is one week from today. (2/9/2006) In class, closed notes Example exam from last year will be

More information

Certification Report

Certification Report Certification Report EAL 4 Evaluation of SecureDoc Disk Encryption Version 4.3C Issued by: Communications Security Establishment Certification Body Canadian Common Criteria Evaluation and Certification

More information

Integrated Network Vulnerability Scanning & Penetration Testing SAINTcorporation.com

Integrated Network Vulnerability Scanning & Penetration Testing SAINTcorporation.com SAINT Integrated Network Vulnerability Scanning and Penetration Testing www.saintcorporation.com Introduction While network vulnerability scanning is an important tool in proactive network security, penetration

More information

Defense in Depth: Protecting Against Zero-Day Attacks

Defense in Depth: Protecting Against Zero-Day Attacks Defense in Depth: Protecting Against Zero-Day Attacks Chris McNab FIRST 16, Budapest 2004 Agenda Exploits through the ages Discussion of stack and heap overflows Common attack behavior Defense in depth

More information

I Control Your Code Attack Vectors Through the Eyes of Software-based Fault Isolation. Mathias Payer, ETH Zurich

I Control Your Code Attack Vectors Through the Eyes of Software-based Fault Isolation. Mathias Payer, ETH Zurich I Control Your Code Attack Vectors Through the Eyes of Software-based Fault Isolation Mathias Payer, ETH Zurich Motivation Applications often vulnerable to security exploits Solution: restrict application

More information

- Table of Contents -

- Table of Contents - - Table of Contents - 1 INTRODUCTION... 1 1.1 TARGET READERS OF THIS DOCUMENT... 1 1.2 ORGANIZATION OF THIS DOCUMENT... 2 1.3 COMMON CRITERIA STANDARDS DOCUMENTS... 3 1.4 TERMS AND DEFINITIONS... 4 2 OVERVIEW

More information

Certification Report

Certification Report Certification Report EAL 3+ Evaluation of Rapid7 Nexpose Vulnerability Management and Penetration Testing System V5.1 Issued by: Communications Security Establishment Canada Certification Body Canadian

More information

CS 392/681 - Computer Security. Module 16 Vulnerability Analysis

CS 392/681 - Computer Security. Module 16 Vulnerability Analysis CS 392/681 - Computer Security Module 16 Vulnerability Analysis Course Policies and Logistics Homework 5 due tonight Homework 6 posted Read Chapter 23 11/13/2003 Module 16 - Vulnerability Analysis 2 Some

More information

Common Criteria Evaluation Challenges for SELinux. Doc Shankar IBM Linux Technology Center dshankar@us.ibm.com

Common Criteria Evaluation Challenges for SELinux. Doc Shankar IBM Linux Technology Center dshankar@us.ibm.com Common Criteria Evaluation Challenges for SELinux Doc Shankar IBM Linux Technology Center dshankar@us.ibm.com Agenda Common Criteria Roadmap/Achievements CAPP/LSPP Overview EAL4 Overview Open Sourcing

More information

D. Best Practices D.1. Assurance The 5 th A

D. Best Practices D.1. Assurance The 5 th A Best Practices I&C School Prof. P. Janson September 2014 D. Best Practices D.1. Assurance The 5 th A 1 of 20 IT systems are insecure for two main reasons: People are fallible and systems are complex and

More information

05.0 Application Development

05.0 Application Development Number 5.0 Policy Owner Information Security and Technology Policy Application Development Effective 01/01/2014 Last Revision 12/30/2013 Department of Innovation and Technology 5. Application Development

More information

Protection and Security [supplemental] 1. Network Firewalls

Protection and Security [supplemental] 1. Network Firewalls Protection and Security [supplemental] 1 Network Firewalls How to connect a trusted computer system to an untrusted network? Put a firewall between the trusted (system or systems) and the untrusted. All

More information

Certification Report

Certification Report Certification Report Symantec Network Access Control Version 12.1.2 Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria Evaluation and Certification Scheme

More information

CIS 551 / TCOM 401 Computer and Network Security

CIS 551 / TCOM 401 Computer and Network Security CIS 551 / TCOM 401 Computer and Network Security Spring 2008 Lecture 8 2/12/08 CIS/TCOM 551 1 Announcements Project 1 has been graded. Project 2: will be posted this week Due March 7th Network intrusion

More information

Reference Guide for Security in Networks

Reference Guide for Security in Networks Reference Guide for Security in Networks This reference guide is provided to aid in understanding security concepts and their application in various network architectures. It should not be used as a template

More information

Software security. Buffer overflow attacks SQL injections. Lecture 11 EIT060 Computer Security

Software security. Buffer overflow attacks SQL injections. Lecture 11 EIT060 Computer Security Software security Buffer overflow attacks SQL injections Lecture 11 EIT060 Computer Security Buffer overflow attacks Buffer overrun is another common term Definition A condition at an interface under which

More information

Columbia University Web Security Standards and Practices. Objective and Scope

Columbia University Web Security Standards and Practices. Objective and Scope Columbia University Web Security Standards and Practices Objective and Scope Effective Date: January 2011 This Web Security Standards and Practices document establishes a baseline of security related requirements

More information

Information Technology Engineers Examination. Information Security Specialist Examination. (Level 4) Syllabus

Information Technology Engineers Examination. Information Security Specialist Examination. (Level 4) Syllabus Information Technology Engineers Examination Information Security Specialist Examination (Level 4) Syllabus Details of Knowledge and Skills Required for the Information Technology Engineers Examination

More information

Certification Report

Certification Report Certification Report EAL 3+ Evaluation of AccessData Cyber Intelligence and Response Technology v2.1.2 Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria

More information

Cryptographic Modules, Security Level Enhanced. Endorsed by the Bundesamt für Sicherheit in der Informationstechnik

Cryptographic Modules, Security Level Enhanced. Endorsed by the Bundesamt für Sicherheit in der Informationstechnik Common Criteria Protection Profile Cryptographic Modules, Security Level Enhanced BSI-CC-PP-0045 Endorsed by the Foreword This Protection Profile - Cryptographic Modules, Security Level Enhanced - is issued

More information

90% of data breaches are caused by software vulnerabilities.

90% of data breaches are caused by software vulnerabilities. 90% of data breaches are caused by software vulnerabilities. Get the skills you need to build secure software applications Secure Software Development (SSD) www.ce.ucf.edu/ssd Offered in partnership with

More information

Web Applications Security: SQL Injection Attack

Web Applications Security: SQL Injection Attack Web Applications Security: SQL Injection Attack S. C. Kothari CPRE 556: Lecture 8, February 2, 2006 Electrical and Computer Engineering Dept. Iowa State University SQL Injection: What is it A technique

More information

Certification Report

Certification Report Certification Report HP Network Automation Ultimate Edition 10.10 Issued by: Communications Security Establishment Certification Body Canadian Common Criteria Evaluation and Certification Scheme Government

More information

The Software Development Life Cycle: An Overview. Last Time. Session 8: Security and Evaluation. Information Systems Security Engineering

The Software Development Life Cycle: An Overview. Last Time. Session 8: Security and Evaluation. Information Systems Security Engineering The Software Development Life Cycle: An Overview Presented by Maxwell Drew and Dan Kaiser Southwest State University Computer Science Program Last Time Brief review of the testing process Dynamic Testing

More information

Technical Standards for Information Security Measures for the Central Government Computer Systems

Technical Standards for Information Security Measures for the Central Government Computer Systems Technical Standards for Information Security Measures for the Central Government Computer Systems April 21, 2011 Established by the Information Security Policy Council Table of Contents Chapter 2.1 General...

More information

Common Criteria. Introduction 2014-02-24. Magnus Ahlbin. Emilie Barse 2014-02-25. Emilie Barse Magnus Ahlbin

Common Criteria. Introduction 2014-02-24. Magnus Ahlbin. Emilie Barse 2014-02-25. Emilie Barse Magnus Ahlbin Common Criteria Introduction 2014-02-24 Emilie Barse Magnus Ahlbin 1 Magnus Ahlbin Head of EC/ITSEF Information and Security Combitech AB SE-351 80 Växjö Sweden magnus.ahlbin@combitech.se www.combitech.se

More information

Certification Report

Certification Report Certification Report EAL 4+ Evaluation of ncipher nshield Family of Hardware Security Modules Firmware Version 2.33.60 Issued by: Communications Security Establishment Canada Certification Body Canadian

More information

Certification Report

Certification Report Certification Report McAfee Network Security Platform v7.1 (M-series sensors) Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria Evaluation and Certification

More information

Joint Interpretation Library

Joint Interpretation Library for smart cards and similar devices Document purpose: provide requirements to developers and guidance to evaluators to fulfill the Security Architecture requirements of CC V3 ADV_ARC family. Version 2.0

More information

Certification Report

Certification Report Certification Report EAL 3+ Evaluation of RSA envision platform v4.0 SP 1 Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria Evaluation and Certification

More information

Chapter 6, The Operating System Machine Level

Chapter 6, The Operating System Machine Level Chapter 6, The Operating System Machine Level 6.1 Virtual Memory 6.2 Virtual I/O Instructions 6.3 Virtual Instructions For Parallel Processing 6.4 Example Operating Systems 6.5 Summary Virtual Memory General

More information

Standard: Web Application Development

Standard: Web Application Development Information Security Standards Web Application Development Standard IS-WAD Effective Date TBD Email security@sjsu.edu # Version 2.0 Contact Mike Cook Phone 408-924-1705 Standard: Web Application Development

More information

Certification Report

Certification Report Certification Report EAL 2+ Evaluation of Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria Evaluation and Certification Scheme Government of Canada, Communications

More information

Build (develop) and document Acceptance Transition to production (installation) Operations and maintenance support (postinstallation)

Build (develop) and document Acceptance Transition to production (installation) Operations and maintenance support (postinstallation) It is a well-known fact in computer security that security problems are very often a direct result of software bugs. That leads security researches to pay lots of attention to software engineering. The

More information

CS52600: Information Security

CS52600: Information Security CS18000: Programming I CS52600: Information Security Vulnerability Analysis 15 November 2010 Prof. Chris Clifton Vulnerability Analysis Vulnerability: Lapse in enforcement enabling violation of security

More information

Secure Software Programming and Vulnerability Analysis

Secure Software Programming and Vulnerability Analysis Secure Software Programming and Vulnerability Analysis Christopher Kruegel chris@auto.tuwien.ac.at http://www.auto.tuwien.ac.at/~chris Testing and Source Code Auditing Secure Software Programming 2 Overview

More information

Certification Report

Certification Report Certification Report EAL 4+ Evaluation of WatchGuard Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria Evaluation and Certification Scheme Government of

More information

Bypassing Memory Protections: The Future of Exploitation

Bypassing Memory Protections: The Future of Exploitation Bypassing Memory Protections: The Future of Exploitation Alexander Sotirov alex@sotirov.net About me Exploit development since 1999 Research into reliable exploitation techniques: Heap Feng Shui in JavaScript

More information

National Information Assurance Partnership

National Information Assurance Partnership National Information Assurance Partnership TM Common Criteria Evaluation and Validation Scheme Validation Report IBM UK Ltd IBM WebSphere Business Integration Message Broker Version 5.0, Fix Pack 4 Report

More information

Certification Report

Certification Report Certification Report EAL 4+ Evaluation of WatchGuard and Fireware XTM Operating System v11.5.1 Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria Evaluation

More information

Where every interaction matters.

Where every interaction matters. Where every interaction matters. Peer 1 Vigilant Web Application Firewall Powered by Alert Logic The Open Web Application Security Project (OWASP) Top Ten Web Security Risks and Countermeasures White Paper

More information

KASPERSKY SECURITY INTELLIGENCE SERVICES. EXPERT SERVICES. www.kaspersky.com

KASPERSKY SECURITY INTELLIGENCE SERVICES. EXPERT SERVICES. www.kaspersky.com KASPERSKY SECURITY INTELLIGENCE SERVICES. EXPERT SERVICES www.kaspersky.com EXPERT SERVICES Expert Services from Kaspersky Lab are exactly that the services of our in-house experts, many of them global

More information

IS TEST 3 - TIPS FOUR (4) levels of detective controls offered by intrusion detection system (IDS) methodologies. First layer is typically responsible for monitoring the network and network devices. NIDS

More information

Data on Kernel Failures and Security Incidents

Data on Kernel Failures and Security Incidents Data on Kernel Failures and Security Incidents Ravishankar K. Iyer (W. Gu, Z. Kalbarczyk, G. Lyle, A. Sharma, L. Wang ) Center for Reliable and High-Performance Computing Coordinated Science Laboratory

More information

Last update: February 23, 2004

Last update: February 23, 2004 Last update: February 23, 2004 Web Security Glossary The Web Security Glossary is an alphabetical index of terms and terminology relating to web application security. The purpose of the Glossary is to

More information

Web Application Threats and Vulnerabilities Web Server Hacking and Web Application Vulnerability

Web Application Threats and Vulnerabilities Web Server Hacking and Web Application Vulnerability Web Application Threats and Vulnerabilities Web Server Hacking and Web Application Vulnerability WWW Based upon HTTP and HTML Runs in TCP s application layer Runs on top of the Internet Used to exchange

More information

CEN 559 Selected Topics in Computer Engineering. Dr. Mostafa H. Dahshan KSU CCIS mdahshan@ccis.ksu.edu.sa

CEN 559 Selected Topics in Computer Engineering. Dr. Mostafa H. Dahshan KSU CCIS mdahshan@ccis.ksu.edu.sa CEN 559 Selected Topics in Computer Engineering Dr. Mostafa H. Dahshan KSU CCIS mdahshan@ccis.ksu.edu.sa Access Control Access Control Which principals have access to which resources files they can read

More information

Information Technology Security Evaluation Criteria ( ITSEC ) Critères d'évaluation de la securitie des systémes informatiques

Information Technology Security Evaluation Criteria ( ITSEC ) Critères d'évaluation de la securitie des systémes informatiques Information Technology Security Evaluation Criteria ( ITSEC ) Critères d'évaluation de la securitie des systémes informatiques Kriterien für die Bewertung der Sicherheit von Systemen der Informationstechnik

More information

Certification Report

Certification Report Certification Report McAfee Enterprise Mobility Management 12.0 Issued by: Communications Security Establishment Certification Body Canadian Common Criteria Evaluation and Certification Scheme Government

More information

Chapter 6: Fundamental Cloud Security

Chapter 6: Fundamental Cloud Security Chapter 6: Fundamental Cloud Security Nora Almezeini MIS Department, CBA, KSU From Cloud Computing by Thomas Erl, Zaigham Mahmood, and Ricardo Puttini(ISBN: 0133387526) Copyright 2013 Arcitura Education,

More information

Certification Report

Certification Report Certification Report EAL 2 Evaluation of with Gateway and Key Management v2.9 running on Fedora Core 6 Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria

More information

NETWORK AND CERTIFICATE SYSTEM SECURITY REQUIREMENTS

NETWORK AND CERTIFICATE SYSTEM SECURITY REQUIREMENTS NETWORK AND CERTIFICATE SYSTEM SECURITY REQUIREMENTS Scope and Applicability: These Network and Certificate System Security Requirements (Requirements) apply to all publicly trusted Certification Authorities

More information

Evaluation Issues. Essay 12. Marshall D. Abrams and Harold J. Podell

Evaluation Issues. Essay 12. Marshall D. Abrams and Harold J. Podell Essay 12 Evaluation Issues Marshall D. Abrams and Harold J. Podell In this essay we present an introduction to evaluation issues in the United States and European Community (EC) to illustrate the two schools

More information

Improving Software Security at the. Source

Improving Software Security at the. Source Improving Software Security at the Source Greg Snyder Privacy & Security RIT January 28, 2006 Abstract While computer security has become a major focus of information technology professionals due to patching

More information

Criteria for web application security check. Version 2015.1

Criteria for web application security check. Version 2015.1 Criteria for web application security check Version 2015.1 i Content Introduction... iii ISC- P- 001 ISC- P- 001.1 ISC- P- 001.2 ISC- P- 001.3 ISC- P- 001.4 ISC- P- 001.5 ISC- P- 001.6 ISC- P- 001.7 ISC-

More information

Example of Standard API

Example of Standard API 16 Example of Standard API System Call Implementation Typically, a number associated with each system call System call interface maintains a table indexed according to these numbers The system call interface

More information

WEB CONTENT MANAGEMENT SYSTEM

WEB CONTENT MANAGEMENT SYSTEM WEB CONTENT MANAGEMENT SYSTEM February 2008 The Government of the Hong Kong Special Administrative Region The contents of this document remain the property of, and may not be reproduced in whole or in

More information

Developing the Corporate Security Architecture. www.avient.ca Alex Woda July 22, 2009

Developing the Corporate Security Architecture. www.avient.ca Alex Woda July 22, 2009 Developing the Corporate Security Architecture www.avient.ca Alex Woda July 22, 2009 Avient Solutions Group Avient Solutions Group is based in Markham and is a professional services firm specializing in

More information

Security Overview of the Integrity Virtual Machines Architecture

Security Overview of the Integrity Virtual Machines Architecture Security Overview of the Integrity Virtual Machines Architecture Introduction... 2 Integrity Virtual Machines Architecture... 2 Virtual Machine Host System... 2 Virtual Machine Control... 2 Scheduling

More information

DATABASE SECURITY MECHANISMS AND IMPLEMENTATIONS

DATABASE SECURITY MECHANISMS AND IMPLEMENTATIONS DATABASE SECURITY MECHANISMS AND IMPLEMENTATIONS Manying Qiu, Virginia State University, mqiu@vsu.edu Steve Davis, Clemson University, davis@clemson.edu ABSTRACT People considering improvements in database

More information

WHITE PAPER. FortiWeb and the OWASP Top 10 Mitigating the most dangerous application security threats

WHITE PAPER. FortiWeb and the OWASP Top 10 Mitigating the most dangerous application security threats WHITE PAPER FortiWeb and the OWASP Top 10 PAGE 2 Introduction The Open Web Application Security project (OWASP) Top Ten provides a powerful awareness document for web application security. The OWASP Top

More information

Information Technology Policy

Information Technology Policy Information Technology Policy Enterprise Web Application Firewall ITP Number ITP-SEC004 Category Recommended Policy Contact RA-ITCentral@pa.gov Effective Date January 15, 2010 Supersedes Scheduled Review

More information

Format string exploitation on windows Using Immunity Debugger / Python. By Abysssec Inc WwW.Abysssec.Com

Format string exploitation on windows Using Immunity Debugger / Python. By Abysssec Inc WwW.Abysssec.Com Format string exploitation on windows Using Immunity Debugger / Python By Abysssec Inc WwW.Abysssec.Com For real beneficiary this post you should have few assembly knowledge and you should know about classic

More information

White Paper. Guide to PCI Application Security Compliance for Merchants and Service Providers

White Paper. Guide to PCI Application Security Compliance for Merchants and Service Providers White Paper Guide to PCI Application Security Compliance for Merchants and Service Providers Contents Overview... 3 I. The PCI DSS Requirements... 3 II. Compliance and Validation Requirements... 4 III.

More information

FINAL DoIT 04.01.2013- v.8 APPLICATION SECURITY PROCEDURE

FINAL DoIT 04.01.2013- v.8 APPLICATION SECURITY PROCEDURE Purpose: This procedure identifies what is required to ensure the development of a secure application. Procedure: The five basic areas covered by this document include: Standards for Privacy and Security

More information

Virtualization System Security

Virtualization System Security Virtualization System Security Bryan Williams, IBM X-Force Advanced Research Tom Cross, Manager, IBM X-Force Security Strategy 2009 IBM Corporation Overview Vulnerability disclosure analysis Vulnerability

More information

Chapter 23. Database Security. Security Issues. Database Security

Chapter 23. Database Security. Security Issues. Database Security Chapter 23 Database Security Security Issues Legal and ethical issues Policy issues System-related issues The need to identify multiple security levels 2 Database Security A DBMS typically includes a database

More information

Security (II) ISO 7498-2: Security Architecture of OSI Reference Model. Outline. Course Outline: Fundamental Topics. EE5723/EE4723 Spring 2012

Security (II) ISO 7498-2: Security Architecture of OSI Reference Model. Outline. Course Outline: Fundamental Topics. EE5723/EE4723 Spring 2012 Course Outline: Fundamental Topics System View of Network Security Network Security Model Security Threat Model & Security Services Model Overview of Network Security Security Basis: Cryptography Secret

More information

Motorola 8- and 16-bit Embedded Application Binary Interface (M8/16EABI)

Motorola 8- and 16-bit Embedded Application Binary Interface (M8/16EABI) Motorola 8- and 16-bit Embedded Application Binary Interface (M8/16EABI) SYSTEM V APPLICATION BINARY INTERFACE Motorola M68HC05, M68HC08, M68HC11, M68HC12, and M68HC16 Processors Supplement Version 2.0

More information

DISCOVERY OF WEB-APPLICATION VULNERABILITIES USING FUZZING TECHNIQUES

DISCOVERY OF WEB-APPLICATION VULNERABILITIES USING FUZZING TECHNIQUES DISCOVERY OF WEB-APPLICATION VULNERABILITIES USING FUZZING TECHNIQUES By Michael Crouse Dr. Errin W. Fulp, Ph.D., Advisor Abstract The increasingly high volume of users on the web and their use of web

More information

Certification Report

Certification Report Certification Report EAL 2+ Evaluation of Symantec Endpoint Protection Version 11.0 Issued by: Communications Security Establishment Canada Certification Body Canadian Common Criteria Evaluation and Certification

More information

Computer Security: Principles and Practice

Computer Security: Principles and Practice Computer Security: Principles and Practice Chapter 24 Windows and Windows Vista Security First Edition by William Stallings and Lawrie Brown Lecture slides by Lawrie Brown Windows and Windows Vista Security

More information

Technical Proposition. Security

Technical Proposition. Security Technical Proposition ADAM Software NV The global provider of media workflow and marketing technology software ADAM Software NV adamsoftware.net info@adamsoftware.net Why Read this Technical Proposition?

More information

Chapter 8 Software Testing

Chapter 8 Software Testing Chapter 8 Software Testing Summary 1 Topics covered Development testing Test-driven development Release testing User testing 2 Program testing Testing is intended to show that a program does what it is

More information

CYBERSECURITY TESTING & CERTIFICATION SERVICE TERMS

CYBERSECURITY TESTING & CERTIFICATION SERVICE TERMS CYBERSECURITY TESTING & CERTIFICATION SERVICE TERMS These Cybersecurity Testing and Certification Service Terms ( Service Terms ) shall govern the provision of cybersecurity testing and certification services

More information

Chapter 8 A secure virtual web database environment

Chapter 8 A secure virtual web database environment Chapter 8 Information security with special reference to database interconnectivity Page 146 8.1 Introduction The previous three chapters investigated current state-of-the-art database security services

More information

White Paper BMC Remedy Action Request System Security

White Paper BMC Remedy Action Request System Security White Paper BMC Remedy Action Request System Security June 2008 www.bmc.com Contacting BMC Software You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information

More information

Adobe Systems Incorporated

Adobe Systems Incorporated Adobe Connect 9.2 Page 1 of 8 Adobe Systems Incorporated Adobe Connect 9.2 Hosted Solution June 20 th 2014 Adobe Connect 9.2 Page 2 of 8 Table of Contents Engagement Overview... 3 About Connect 9.2...

More information

Computer Security: Principles and Practice

Computer Security: Principles and Practice Computer Security: Principles and Practice Chapter 10 Trusted Computing and Multilevel Security First Edition by William Stallings and Lawrie Brown Lecture slides by Lawrie Brown Trusted Computing and

More information

Declaration of Conformity 21 CFR Part 11 SIMATIC WinCC flexible 2007

Declaration of Conformity 21 CFR Part 11 SIMATIC WinCC flexible 2007 Declaration of Conformity 21 CFR Part 11 SIMATIC WinCC flexible 2007 SIEMENS AG Industry Sector Industry Automation D-76181 Karlsruhe, Federal Republic of Germany E-mail: pharma.aud@siemens.com Fax: +49

More information