Contents

Security/Privacy Domain Technology Categories

• Policies
• Access Control and Authentication
• Directory Services
• Anti-Virus Products
• Awareness Tools
• Biometrics
• Firewalls
• Encryption
• Intrusion Detection
• Security Administration
• Software Controls
• Physical Security
• Telecommunication and Remote Access Security
• Digital Signatures
• Public/Private Key Infrastructure (PKI)

Principles for the Security Architecture Domain

1. Education and Awareness
   • End User Security Awareness - Know Your Responsibilities (Power Point)
   • Security for Programmers (Power Point - 9/2004)
   • UC Office Of President - Information Security
   • UC Office Of President - HIPAA
   • UC Irvine Security
   • Security awareness education and training (to be organized).
   • Security laws and policies campus personnel must be familar with
     • Comprehensive List of Laws and Policies
     • Federal laws on privacy regulations
       • Family Educational Rights and Privacy Act (FERPA)
       • Health Insurance Portability and Accountability Act (HIPAA)
       • Digital Millennium Copyright Act
       • Federal Trade Commission - Gramm-Leach-Bliley Act on Customer Privacy
       • USA Patriot Act of 2002
     • State laws on privacy regulations
       • SB1386
     • Campus security policies.
       • Computing Policy and Information Systems

         714-11	Guidelines for NACS Computer Usage
         714-12	Office of Academic Computing Policy on Ownership and Rights of Access to Software and Data
         714-14	Copying Computer Programs
         714-15	Policy on Access to University Administrative Information Systems
         714-16	Procedures for Accessing University Administrative Information Systems
         714-17	Using University Administrative Information Systems
         714-18	Computer and Network Use Policy

2. The Security Architecture must facilitate proper and efficient identification, authentication, authorization, administration and auditability and adhere to the general architecture outlined in User Management and Access Control Architecture
3. Centralize security policy, maintenance operation and oversight functions.
4. Delegate access control where appropriate.
5. Security will be commensurate with the business need/mandate and risk. Risk analysis should decide if the cost for security protection is appropriate to the level of security required.
6. Minimize the number of security devices
7. Consider security during initial system design
8. Security should ensure but not impede connectivity
9. Assign Security levels consistently and at the lowest level of access required by the individual.
10. Provide a modular approach to authentication, authorization, and accounting.
11. Provide for various strength Authentication models.
12. Provide for portability across platforms.
13. Utilize Open Standards.
14. Support multiple interfaces to the security infrastructure.
15. The Security Architecture must be flexible to support the introduction and/or integration of new technologies.
16. Ensure that the accountability and responsibility of all persons fulfilling security duties is sustainable and enforceable.
17. The Security Architecture must address and support multiple levels of protection, including network level, operating system, and application level security needs.

Existing Security Practices Governing AdCom Activity

• Prevention
  1. NACS scans campus computers for vulnerabilities using FoundScan (Mike Iglesias).
  2. AdCom processes NACS FoundScan security vulnerability reports within 24 hours for all HIGH level vulnerabilities. MEDIUM level vulnerabilities are fixed within 1 week.
  3. All passwords are submitted over encrypted links except for EMAIL.
  4. Windows, Linux, Solaris, and Mainframe OS and all supported vendor software is kept within 2 releases of the latest software.
  5. Emergency bug fixes or patches are installed on all systems once available.
     1. DB2, Sybase, Apache, Tomcat, and Websphere patches are installed within 24 hours of posting.
     2. Microsoft OS, SQL Server, MTS, and IIS Server patches are installed within 12 hours of posted advisories.
  6. Every 6 months, a password cracking utility called Crack is run and users notified of badly chosen passwords.
  7. All applications undergo a security review during design and implementation phase.
  8. Encryption of all sensitive connections and data is in place or in progress.
  9. CERT Advisories are reviewed.
  10. Sophos virus scanning softare is used on the @apollo.adcom.uci.edu domain. Greentree resume feeds are scanned for viruses using this tool.
• Identification/Authentication
  1. WebAuth is used for all web applications. OS390 RACF passwords are used for CICS applications. Unix passwords are used for EMAIL. Sybase, DB2, MS SQLServer, and Mysql passwords are created and maintained as necessary.
  2. A Person Registry database is used to validate all individuals who have access privileges to applications.
  3. Windows machines with sensitive information have screen savers and passwords enabled.
• Authorization/Access Control
  1. Access control of "Separated" individuals or individuals whose status has changed is maintained.
  2. Formal sign-off by Registrar is required before any student related data is provided from SBS or DWH.
  3. Formal sign-off by Human Resources and/or Payroll Personnel is obtained before private employee data is available.
  4. SAMS centralizes access control to applications.
  5. Physical Access control
     • The AdCom Data Center is access controlled.
     • The main office and auxilliary offices of AdCom Services are controlled between the hours of 5 pm and 8 am.
• Detection
  1. Logs are analyzed monthly for intrusion.
  2. Intruder Detection Checklist (CERT)
• Recovery
  1. Steps for Recovering from a UNIX or NT System Compromise (CERT)
• Auditing
  1. Yearly audits by Internal Controls are conducted.

Security Advisories, Vulnerabilities and Checklists

• NACS Services
  • NACS Security Alerts, Announcements and Information.
  • NACS Virus information.
• CERT Alerts
• CERT Advisories
• SANS Security Newsletters
• SANS Twenty Most Critical Internet Security Vulnerabilities for Unix and Windows
• UC Davis Top Ten Security Exposers
• Microsoft Security Checklists
• Tigris Security Checklists

Product/Technology Life Cycle Matrix

This is a sliding 16 quarter window in Calendar years. The date range of the Calendar year is January 1 through December 31 and corresponds to industry conventions.




Access Control and Authentication

			2007				2008				2009				2010
Tool/Technology	Platform	Usage/Type	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4
Access Control Model for LDAPv3, Internet Engineering Task Force		Standard	W	W	W	W	W	W	W	W	W	W	W	W	W	W	W	W
NT 4.0 Domain Services	Microsoft	File and Printer Access Control	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O	O
Samba	Linux, Microsoft	Workstation File and Printer Access Control. Chains to LDAP.	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
Public Private Key Infrastructure (PKI)	All	Authentication and Digital Signatures	P	I	I	I	W	W	W	W	W	W	W	W	W	W	W	W
Active Directory	Microsoft	Directory Services	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C	C
OpenLDAP	Unix	Directory Services	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
Security Access Maintenance System (SAMS)	Unix/Sybase	Homegrown	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
Distributed Access Control System - DACS	Mainframe	Homegrown	M	M	M	M	M	M	M	M	M	M	M	M	M	M	M	M
JavaCorporate Expresso User Management	All	Application Development Framework	M	M	M	M	M	M	M	M	M	M	M	M	M	M	M	M
Kerberos	All	Authentication	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
WebAuth	Web	NACS Homegrown, Kerberos	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
Apache Web Server	Unix, Microsoft	IP Restriction	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
MS IIS Web Server	Microsoft	IP Restriction	D	D	D	D	D	D	D	D	D	D	D	D	D	D	D	D
Grouper/Signet	All	Group / Privilege Management					R	R	R	R	R	R	R	R	R	R	R	R
Spring Security		Authentication / Authorization					I	I	I	I	I	I	I	I	I	I	I	I
RSA SecurId		Authentication					I	I	I	I	I	I	I	I	I	I	I	I
Enterprise Password Safe		Password management					R	I	I	I	I	I	I	I	I	I	I	I

Remote Access

			2007				2008				2009				2010
Tool/Technology	Platform	Usage/Type	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4
VNC		Remote Access	D	D	D	D	C	C	C	C	C	C	C	C	C	C	C	C
Remote Windows Desktop	Windows Server	Remote Access	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
VPN - PPTP & IPSec	Linux	Remote Access Server	D	D	D	D	D	D	D	D	D	D	D	D	D	D	D	D
VPN/Cicso/SSL IPsec	Appliance (Hardware)	Remote Access	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I

Anti-Virus

			2007				2008				2009				2010
Tool/Technology	Platform	Usage/Type	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4
Sophos	Unix, Microsoft	Server-side (Unix), Desktop, and Email Virus Detection	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
McAffee Virus	Windows	PC/Eudora Virus Detection	D	D	D	D	D	D	D	D	D	D	D	D	D	D	D	D

Intrusion Detection

			2007				2008				2009				2010
Tool/Technology	Platform	Usage/Type	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4
NACS/DCS Perl Script	Solaris only	Vulnerability scanning. Done quarterly	I	I	I	I	D	D	D	D	D	D	D	D	D	D	D	D
NACS - CyberCop from NAI	Microsoft Only	Mostly MS IIS Server and SQL Server vulnerability scanning done monthly to quarterly (irregular).	I	I	I	I	D	D	D	D	D	D	D	D	D	D	D	D
Snort	Linux only		I	I	I	I	D	D	D	D	D	D	D	D	D	D	D	D
OSSEC	*nix server, Win/*nix/Mac agent	Host based intrustion detection, alerting, rootkit check, system file/registry check, rule based log management/scanning	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R
Apache mod_security		HTTP Traffic Logging				R	R	R	R	R	R	R	R	R	R	R	R	R

Centralized Log Management

			2007				2008				2009				2010
Tool/Technology	Platform	Usage/Type	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4
Syslog-NG	*nix	Homegrown solution using syslog-ng on central server	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
OSSEC	*nix server, Win/*nix/Mac agent	Host based intrustion detection, alerting, rootkit check, system file/registry check, rule based log management/scanning	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R
Splunk	*nix	Centralized log management.	R	R	R	R	I	I	I	I	I	I	I	I	I	I	I	I
rsyslog	*nix	Log management							W	W	W	W	W	W	W	W	W	W

Encryption

			2007				2008				2009				2010
Tool/Technology	Platform	Usage/Type	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4
SSL, SFTP, SSH, STunnel	All	Host to host and terminal to host communication encryption.	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
PGP for Email		Ensures privacy and encryption of email.	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
GPG		Open source encryption.	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
Sybase Encryption		Database column encryption	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
Java Cryptography Extension (JCE)		Programmatic database field encryption	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I

Vulnerability Scanning

			2007				2008				2009				2010
Tool/Technology	Platform	Usage/Type	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4	Q1	Q2	Q3	Q4
Foundstone	All	Network/Server vulnerability scanner	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
SiteDigger	Windows	Google hacking scanner	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
SSLDigger	Windows	Assess strength of SSL servers	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
Wikto	Windows	Web server vulnerability & Google hacking scanner	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
Watchfire Appscan	Windows	Web application vulnerability scanner	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I	I
Scuba		PCI/Security scanning for databases				I	I	I	I	I	I	I	I	I	I	I	I	I
MBSA		Microsoft product vulnerability scanner				I	I	I	I	I	I	I	I	I	I	I	I	I

Best Practices

• In assigning the level of risk, AdCom Services should evaluate both the probability of an event occurring and the resultant effect of that event on the confidentially, availability, and integrity of system components and data.
• Security Awareness
  • Security Awareness programs should contain content that covers, but is not limited to:
    • Responsibility of users to report issues
    • Users can be audited
    • Legal requirements for data (citing legislation as appropriate)
    • Privacy expectations
    • Ownership of data
    • Acceptable use policy for E-mail and Internet Browsers
    • Sensitivity to threats, risks, vulnerabilities
  • Security Awareness programs should include a means to promote security awareness on an on-going basis, i.e., supplemental to training (e.g., security awareness banners, posters, "security day", etc.)
  • Security Awareness training content is not static, and should be continuously reviewed and updated by AdCom Services as needed to reflect changes to the environment, business, technology, systems and information.
• Authentication, Authorization, and Encryption
  • Operation system authentication should be replaced by network authentication. For example, Kerberos authentication should replace Unix, IBM RACF, or Windows authentication.
  • Although it is a proprietary solution, the NACS WebAuth utility should be used whereever possible to simulate single-signon. This utility will be phased out in favor of industry standard solutions once they are made more affordable or available.
  • AdCom Services should consider using certification programs to promote high-level, up-to-date technical security expertise.
  • AdCom Services should subscribe to industry and vendor security mailing lists for the appropriate system components.
  • AdCom should identify a method of verifying user authenticity on a spectrum from "null/weak" to "strong" authentication methods. Authentication is based on validating the following three criteria presented by the user: 1) "What do you know?", 2) "What do you have?", and 3) "Who are you?". Weak authentication is based on validating one of these criteria only, and should only be used when a minimum level of authentication is desired. Strong authentication, which is based on validating two or more of the criteria, should be used in all other cases.
  • AdCom should establish policy and procedures that address when different levels of encryption, digital signatures, and digital certificates are appropriately used.
  • Digital signature and digital certificate technology can be used to verify the authenticity of electronically transmitted data.
  • With regards to Digital Signatures, AdCom should use the UC Public Key Infrastructure wherever possible, and should adhere to the control and auditing practices established to support the use of digital certificates.
  • AdCom should establish Encryption Key Management policy and procedures to address the integrity and recovery of the "keys".
  • AdCom should identify criteria governing the number of unsuccessful login attempts allowed by a user, and the resetting of passwords.
  • Authorization should use role-based access models.
  • AdCom should use single sign-on technology where appropriate.
  • AdCom should strongly consider encryption to protect sensitive data, including passwords, that are transmitted over a public or internal network (e.g., replace Telnet with SSH, HTTP with HTTPS).
• Data Security
  • Desktop platforms, including laptops, should have a protected screen saver mechanism, which is activated.
  • Automatic protected screen savers should be initiated by the system after a specific period of inactivity.
  • Auditable user agreements should be utilized to delegate responsibility for data security from data owners to data custodians. Custodians are responsible for ensuring that the levels of required protection are followed.
• Systems Interoperability Security
  • AdCom should use open standard-based security solutions, as opposed to unique generated security solutions, to support current interoperability needs and to position them for future interoperability needs.
  • AdCom should use open standard based encryption algorithms when sharing sensitive data internally; and externally for data that requires encryption that is resident on that system.
  • New deployments of VPN (Virtual Private Network) technologies should use IPSec (Internet Protocol Security).
  • E-mail should not be considered a secure transport in itself. Therefore, any attachment containing sensitive information should be encrypted (e.g., using Pretty Good Privacy (PGP)).
  • Unencrypted Telnet, FTP, or R-Utilities should not be used.
  • Secure Shell Protocol (SSH) and Secure Hypertext Transfer Protocol (SHTTP) should be deployed for remote terminal sessions and file transfers.
  • 40 bit encryption should be used with SSL transactions to ensure global interoperability unless there is a requirement to use a higher bit encryption.
  • 1024 bit key digital server certificates should be used for SSL.
  • Digital certificates infrastructure should seek interoperability with those digital certificates utilized by other public and government bodies( Federal, State, and Local).
• Physical Security
  • Mission critical system components should be located in an environmentally friendly area (e.g., which includes fire protection, HVAC, UPS).
  • Access to computer hardware, wiring, displays and network should be controlled by documented and enforceable rules.
  • System configurations (i.e., hardware, wiring, displays, network) should be documented. Installations and changes to those physical configurations should be governed by a formal change management process.
  • Physical Access security for back-up systems should be equivalent to that of the primary facilities.
  • A system of monitoring and auditing physical access to computer hardware, wiring, displays and networks should be implemented (e.g., access logs).
• Personnel Security
  • AdCom should establish and document the process which directs the steps and the timing required to grant and withdraw physical and system access privileges to personnel for the following events: new hire, employee transfer to another department, employee termination, employee resignation, employee change of job duties, and perceived disgruntled employee behavior. A similar process should be established for contractors.
  • System access should be granted via a formal and auditable process, and should be accompanied by security training which is commensurate to one's duties and responsibilities.
  • Background checks of personnel may be required consistent with policy and depending on the sensitivity of information accessible to that position.
• Threat Detection
  • Violations should trigger an appropriate form of security notification to security administrators or security staff.
  • Systems should be designed to handle both passive and active alarms.
  • A security event log should be kept for every system. These logs should be analyzed, correlated and evaluated to identify and respond to suspicious activity.
  • Security logs should be archived on a daily basis.
  • Security logs should be moved off the device as soon as possible and stored on an off-site location.
  • Intrusion detection systems should be deployed
  • AdCom should get assistance from the NACS Security team as needed to trouble shoot unusual or "difficult to isolate" threats.
• Security Tool Kit
  • Firewall technology should be implemented to protect sensitive internal information.
  • AdCom should have the ability to monitor and capture traffic at any location within the network (e.g. via use of a portable sniffer).
  • Network and host vulnerability scanners to test for the vulnerabilities of systems must be used.
  • AdCom should scan all incoming e-mail for existence of malicious code (e.g., viruses), and contain and eradicate that code.
• An Incident Reporting Plan (IRP) should detail the steps to be taken to identify, notify, contain, eradicate, recover from, record and report incidents.
• Auditing Systems Activities
  • System configurations and software change over time. Therefore, AdCom should audit security devices, (e.g., firewalls, routers, secured servers such as E-mail gateways, etc.) on a periodic basis to determine if compliance to security policies is being met.
  • AdCom should have a security audit performed by a qualified and approved auditing party on an annual basis.
  • AdCom should use a qualified and approved auditing party to perform E-Commerce audits on an annual basis.