INF 526 Secure Systems Administration Accreditation and Acceptance

INF 526: Secure Systems Administration Accreditation and Acceptance Testing Prof. Clifford Neuman Lecture 14 19 April 2017 OHE 100 C

NEXT LECTURE DATE CHANGE Our next and final meeting, originally scheduled for Wednesday April 26 th, has been moved. We will now meet on: Thursday April 27 th, 2 PM in OHE 100 C 2 PM-2: 50 Presentation by Groups on Exercise 2 2: 50 -3: 20 Review for Final Exam 3: 30 -5: 20 We move to the INF Lab for demonstrations and assessment of the group exercise. 1

Today’s Lecture Andrew Gronski - Accreditation and acceptance testing Additional material on Accreditation and acceptance testing Ankit Srivastav – Student Presentation on Linux Security Break into groups for work on group lab exercise 2 2

INF 526: Secure Systems Administration Accreditation and Acceptance Testing Andrew Gronski

Accreditation and Acceptance Testing • Accreditation – Trust that you are getting what you are supposed to • Acceptance Testing – Testing to gain the trust that what you are getting what you are supposed to

Why Accreditation and Acceptance Testing? • Cost – Cheaper to buy components and systems than to design and build from scratch – Sometimes cheaper solutions exist, but come from a potentially untrustworthy suppliers • Convenience/ Expertise – Creator might recognize it is easier to buy a component or system already on the market than design one – Creator might recognize they do not have the expertise to design the needed system • Still must trust system

Trust When Designing System • Trust by own design • Trust by using trusted supplier • Trust by testing

Trust By Own Design • Least amount of risk that something malicious will be introduced to the system • Trust solely depends on the confidence in the design of the system • If hardware is needed, must be either built inhouse or trust must be obtained in a different way.

Trust By Using Trusted Supplier: Accreditation • Obtain components, subsystems or entire systems from a proven, trusted supplier. • Supplier has proven over time to provide functional, secure products • Trust can be gained through reputation of product or supplier • Concern: Supply Chain

Trust By Testing: Acceptance Testing • For component, subsystem or system not trusted either by design or coming from a trusted supplier • Functionality Testing • Security Testing • Testing can be costly

Level of Trust • Level of trust needed is decided by two main factors: • Criticality – The more critical the component/system, the more trust needed • Cost/Budget – Budget might limit amount of trust obtained, presents a risk – Low cost components/systems might not make sense to spend money testing when new components can just be bought (criticality of component also important)

Authorization Process within Air Force • Other branches of military use similar processes, also similar processes for functionality. Will focus on Cyber Security process • Goal: Obtain ATO (Authorized to Operate) or ATC (Authorized to Connect) – ATO typically for Aircraft, ATC typically for support equipment • Process for Cyber Security: Risk management Framework (RMF)

RMF • • • 1. Categorize System 2. Select Security Controls 3. Implement Security Controls 4. Assess Security Controls 5. Authorize Information Systems 6. Monitor Security Controls

1. Categorize System • A categorization package is created that describes the system • System Architecture, Data Flows and an initial risk assessment (mainly documenting possible threats to the system) are created. • There are different authorizing officials (AO) and technical advisors for different types of systems – – Fighter Planes Bomber Planes Armament (Bombs and other weapons) Support Equipment

2. Select Security Controls • Security Controls are Security Mechanisms – Technical Controls- Ex. Lock out user after 3 incorrect logins – Operational Controls- Ex. EFB not allowed to be used for unauthorized purposes – Management Controls- Ex. Incident Response • Baseline List of Security Controls created by NIST • Each directorate (system type) has a general guideline to what security controls are applicable to that type of system • Program will then use these guidelines to create a list of the security controls applicable to their system

3. Implement Security Controls • Take the controls chosen to be applicable to the system and implement them, if not already implemented • Update documents like system architecture, software and hardware lists to include new security controls

4. Assess Security Controls • Test (and document) results of security controls • This mainly is used for technical security controls • Risk assessment is now updated with vulnerabilities (security controls that have not been implemented). Vulnerabilities that have a threat matched to them produce a risk. • Risk is evaluated and proven to show it is at an acceptable level (or there actions that can be taken to lower the risk to an acceptable level)

4. Assess Security Controls • This is where accreditation and acceptance testing comes in • Most Air Force equipment is bought, not built. Testing to make sure equipment behaves as needed is vital. • If the system plans to use a commonly used piece of equipment (either commercially or by other Air Force systems) generally less testing is needed (accreditation). • However, if a program is planning on using a unique piece of equipment, more testing is needed (acceptance testing)

4. Assess Security Controls • Program might chose unique equipment due to cost or a unique functionality • This equipment needs more functional a long with security testing. Functional testing is not related to cyber security though, and is done separately. Security testing is done by AFRL (Air Force Research Labs) • Also, unique equipment needs more analysis to decide if it is secure. Acceptance is not just based on the equipment itself, but also the maintenance and other factors

4. Assess Security Controls • Currently, program office approach is to buy cheaper equipment and test • AFRL leadership pushing to change approach, as testing is costly and not always easy to accomplish • Personal Experience

5. Authorize Information Systems • Risk Assessment and POAM (plan of action and milestones) are presented to an Authorizing Official • Authorizing Official either decides risk is acceptable (and assumes the risk) and gives program an ATO, or decides risk is unacceptable and more security needs to be implemented to the system. • Authorizing Official is familiar if equipment is accredited or not, can tell program office more acceptance testing is needed.

6. Monitor Security Controls • Once system is given ATO, program must now monitor that the security controls are being implemented properly • ATO’s must be renewed (typically one or two years) • Program continuously goes through RMF process (skipping step 1), sometimes having to select new updated security controls

Authorization Process: Accreditation • Accreditation works in two ways within the authorization process • 1. Accreditation of components or subsystems being bought requires less acceptance testing. • 2. ATO is an accreditation. Once system receives ATO, it is accredited that all of the air force will recognize this system’s ability to operate securely

Military View • Accreditation is better than acceptance testing, however budget and criticality of component dictates what will be done • Risk assessment is key • Similar process is used to determine functionality of a system (such as if a plane is able to fly or not), but a whole authorizing process for just security related performance shows the emphasis put on security

Accreditation and Acceptance Testing in Industry • Industries also must perform some sort of testing on products they buy • However, industries typically put more emphasis on functionality and availability than security (Microsoft acceptance testing example) • Accreditation in industry is related to who a company will purchase from • Acceptance Testing in industry used more as a way to validate a contract and provide payment

Accreditation in Industry • Industries tend to buy from established companies that have proven to provide products that work • Example: Microsoft Office • However, this also applies to when companies need new software built for them. 25

Accreditation in Industry • Software purchase agreements are made whenever a company is purchasing software. • Accreditation comes into play in a couple of ways. • 1. Company might only be willing to buy software from an accredited source • 2. Company might give me leeway on a contract given to an accredited source (in how much acceptance testing is needed before 26

Acceptance Testing in Industry • Companies often provide contracts to a different company to build something they need. • Acceptance Testing is used to: • 1. Keep the company on contract on track • 2. Provide a concrete way to test the product, if it does not pass the tests the company won’t get paid the full amount 27

Acceptance Testing in Industry • For a big system, acceptance testing is very important • A company will provide in the contract tests it will perform on the product before the final purchase is made. • Typically functionality related, but security is becoming a bigger part. 28

Microsoft Acceptance Testing

Apple Acceptance Testing • Looking for user acceptance testing • This implies functionality (a long with usability) • Security acceptance testing is also done though, and a list of certifications and validations can be found online (link provided shows acceptance testing and certificates for cryptographic methods used in i. OS). – https: //support. apple. com/en-us/HT 202739

Accreditation and Acceptance Testing • Accreditation is used to provide trust without the need for additional (possibly costly) testing • Acceptance Testing provides trust that is absent when no accreditation is in place.

Linux System Security By Ankit Srivastav 3728039676

Points to be discussed ● Discretionary Access Controls ● Typical vulnerabilities and exploits in Linux ● Best practices for mitigating those threats ● New improvements to Linux security model

Linux Security Linux has evolved into one of the most popular and versatile operating systems. ●Many features mean broad attack surface. ●Can create highly secure Linux systems. ●Linux’s traditional security model is: ● –people or proceses with “root” privileges can do anything. –other accounts can do much less hence attacker’s want to get root privileges. ●Can run robust, secure Linux systems. ●Crux of problem is use of Discretionary Access

Linux Security Transactions

File System Security In Linux everything as a file. ➢Example memory, device-drivers, named pipes, and other system resources. ➢Hence why filesystem security is so important. ●I/O to devices is via a “special” file. ➢Example /dev/cdrom ● Have other special files like named pipes. ➢A conduit between processes / programs. ●

Users and Groups ● A user-account (user) ➢represents someone capable of using files ➢associated both with humans and processes ●A group-account (group) ➢is a list of user-accounts ➢users ➢may have a main group also belong to other groups ●Users & groups are not files

Users and Groups User's details are kept in /etc/password ●Additional group details in /etc/group ● ● Use useradd, usermod, userdel to alter

File Permissions Ffiles have two owners: a user & a group. ●Each with its own set of permissions. ●With a third set of permissions for other. ●Permissions are to read/write/execute in order user/group/other, cf. ● -rw-rw-r-- 1 maestro user 35414 Mar 25 01: 38 baton. txt ● Set using chmod command.

Directory Permissions Read = list contents ●Write = create or delete files in directory ●Execute = use anything in or change working directory to this directory ●Example. $ chmod g+rx extreme_casseroles ● $ ls -l extreme_casseroles drwxr-x--- 8 biff drummers 288 Mar 25 01: 38 extreme_casseroles

Sticky Bit Originally used to lock file in memory ●Now used on directories to limit delete ● ➢if set must own file or dir to delete ➢other ● users cannot delete even if have write Set using chmod command with +t flag, e. g. chmod +t extreme_casseroles ● Directory listing includes t or T flag drwxrwx--T 8 biff drummers 01: 38 extreme_casseroles ● 288 Only apply to specific directory not child dirs Mar 25

Kernel vs User Space ● Kernel space ➢refers to memory used by the Linux kernel and its loadable modules (e. g. , device drivers) ●User space ➢refers to memory used by all other processes ➢since kernel enforces Linux DAC and security critical to isolate kernel from user ➢so kernel space never swapped to disk ➢only root may load and unload kernel modules

Set. UID Root Vulnerabilities ● A setuid root program runs as root ➢no matter who executes it Used to provide unprivileged users with access to privileged resources (e. g. change passwd) ●Must be very carefully programmed ●If can be exploited due to a software bug ● ➢May allow otherwise-unprivileged users to use it to wield unauthorized root privileges Distributions now minimize setuid-root programs ●System attackers still scan for them! ●

Web Vulnerabilities ● A very broad category of vulnerabilities ➢because surfaces ● of ubiquity of world wide web have big and visible attack When written in scripting languages ➢not as prone to classic buffer overflows ➢can suffer from poor input-handling Few “enabled-by-default” web applications ●But users install vulnerable web applications ●Write custom web applications having easily-identified and easily-exploited flaws ●

Rootkits Allow attacker to cover their tracks ●If successfully installed before detection, all is very nearly lost ●Originally collections of hacked commands ● ➢ ● hiding attacker’s files, directories, processes Now use loadable kernel modules ➢intercepting ➢hiding system calls in kernel-space attacker from standard commands May be able to detect with chkrootkit ●Generally have to wipe and rebuild system ●

Network Access Controls Network a key attack vector to secure ●TCP wrappers a key tool to check access ● ➢originally ➢before tcpd inetd wrapper daemon allowing connection to service checks ● if requesting host explicitly in hosts. allow is ok ● if requesting host explicitly in hosts. deny is blocked ● if not in either is ok ➢checks ➢now on service, source IP, username often part of app using libwrappers

Root Delegation Have "root can to anything, users do little” issue ●“su” command allows users to run as root ● ➢either ➢must root shell or single command supply root password ➢means likely too many people know this SELinux RBAC can limit root authority, complex ●“sudo” allows users to run as root ● ➢but only need their password, not root password ➢/etc/sudoers ● file specifies what commands allowed Configure user/group perms to allow, tricky

Logging Effective logging a key resource ●Linux logs using syslogd or Syslog-NG ● ➢receive ➢sorts log data from a variety of sources by facility (category) and severity ➢writes log messages to local/remote log files ●Syslog-NG preferable because it has: ➢variety ➢much ➢an of log-data sources / destinations more flexible “rules engine” to configure log via TCP which can be encrypted ●Should check and customized defaults

Modularity Applications running as a single, large, multipurpose process can be: ● ➢more difficult to run as an unprivileged user ➢harder to locate / fix security bugs in source ➢harder to disable unnecessary functionality ●Hence modularity a highly prized feature ➢providing a much smaller attack surface ●Cf. postfix vs sendmail, Apache modules

Encryption Sending logins & passwords or application data over networks in clear text exposes them to network eavesdropping attacks ●Hence many network applications now support encryption to protect such data ● ➢often using Open. SSL library ●May need own X. 509 certificates to use ➢can generate/sign using openssl command ➢may use commercial/own/free CA

Mandatory Access Controls Linux uses a DAC security model ●But Mandatory Access Controls (MAC) impose a global security policy on all users ● ➢users may not set controls weaker than policy ➢normal admin done with accounts without authority to change the global security policy ➢but MAC systems have been hard to manage Novell’s Su. SE Linux has App. Armor ●Red. Hat Enterprise Linux has SELinux ●Pure SELinux for high-sensitivity, high-security ●

Second Exercise - Criminal Enterprises • Chosen because of differences in the high level principles. – Not because I expect you to implement these kinds of systems in your future endeavors. – But you may be called upon to break some of these systems if later employed by government organizations. • Your organization must: – – – Accept Bitcoin as payment (not really, but it must accept something that stands in for bitcoin) Manage an inventory of stolen account identifiers with passwords Control access to such information Prevent collection of evidence or intelligence by third parties. Note, do not deal in any illegal goods, but use dummy information to stand in for such goods. Also, do not use terms associated with such illegals goods or information in communications, make up new names for this dummy information. 52

Group Report for Lab Exercise 2 By today each team has submitted: • A network diagram: – including your virtual machines and other systems like client browsers – Show containment regions • A description of all software components used in the implementation of your scenario, including: – Application software components (e. g. databases, servers) – Security software components – Administration and management software components • For each software component: – Describe where it is installed – Where obtained (or written yourself), and version information » How you manage updates – A table listing the authorized information flows. • For the system as a whole – List tools used to monitor, detect and recover from intrusions – What kind of red-teaming or pen-testing you performed – A risk assessment – what threats do you defend against, how do you mitigate impact of an attack, what are you still vulnerable to, and justification for your decisions regarding such threats. 53

By the Final Lecture in two weeks Alternate Date April 27 th • Each group should prepare a report describing: – User documentation for their application (high level) – Their network and server architecture (what servers are on what VM’s and how they are interconnected) – A risk assessment/vulnerability analysis enumerating the risks, explaining the mitigation of those risks, and listing those threats that are not defended against (i. e. where you accept the risks). – A description of the steps taken for pen testing of your system. • Each group will have 20 minutes to present, and then 20 minutes to demonstrate their project. We will have 20 minutes following gthe presentations and demonstrations for limited pen-testing. – Procedures and Rules to be determined 54