Incident Response

I was recently asked to respond to the hypothetical situation “We just got hacked! Customer data is compromised. Build out a bulleted checklist of 10 things you need to do next.”

I could come up with only two. This is what you do next.

1.  Take out your incident response checklist and start gathering information.

• What is the initial indicator of the event?
• When did the initial indicator occur?
• Who identified the initial indicator?
• Is the indicator continuing to occur?
• Has the initial indicator evolved?
• Have any additional personnel been notified? Are they working on the event presently?
• What business processes are affected?
• What assets are affected and to what degree? For example, is there a system outage? Has intellectual property been lost? Has personally identifiable information been lost?

You are in the Identification phase of your Incident Response Plan. Document the current situation and why (in the hypothetical situation described) you believe customer data may be compromised.

2.  Take out your incident response team contact list and start calling the team members.

You are in the Containment phase of your Incident Response Plan. Let your incident response team know that customer data may have been compromised. Pass along the information from your incident response checklist.

That was what you do next. These two phases (Identification and Containment) should take minutes to complete. That requires preparation. What you do next relies upon what you did before.

A take-away from this exercise: If you are the on-call person, you have an incident response checklist and you have an incident response contact list. These should be physical, paper objects; do not rely upon computer access for your incident response documents.

These documents were created as part of preparatory work you have done; that is, they are products of the Preparation phase of your Incident Response plan.

With Preparation, Identification, and Containment phases complete, you move on to the Eradication, Recovery, and Lessons Learned phases.

What happens during the Eradication, Recovery and Lessons Learned phases will vary. For example, if a thumb drive containing unencrypted customer data has been lost, then you have limited next steps. Inform the executive, consult with the legal and public relations teams, and (in all likelihood) contact customers promptly.

On the other hand, if you see that an unknown person has system access, your actions would be more involved. The Containment phase has taken the system with customer data offline. The Eradication phase has determined how access was obtained and taken measures to prevent access from being restored once the customer data is back online. The customer data would no longer be trustworthy. The Recovery phase would require restoration from a known good backup. Updates since the backup have been lost. The Lessons Learn phase would implement measures that prevent access in the future.

You want your Preparation phase to go through more than these two scenarios in order to flesh-out the contact list, containment measures, eradication measures, and recovery measures. The incident response checklist should be fairly complete, but table-top exercises may indicate that other questions should be asked as well.

---

Can we get Joe Gray‍’s presentation “Dear Blue Team: Forensic Advice for System Admins, Engineers, and other Blue non-forensicators” (RSA, April 18, 2016)? That would be appropriate here. YouTube, slides on Peerlyst.

---

As part of your “malware detected” playbook, include VirusTotal (the premium offering, VirusTotal Intelligence, is preferred). See the SANS Webcast “Advanced Malware Threat Hunting and Investigation with VirusTotal Intelligence” (Apr 24, 2018).

Checking Your Web Application

To check for broken links:

• Web QA Test Tools
• W3C Validator
• Xenulink

To check Cascading Style Sheets (CSS):

• CSS Validator

To check for exposed directory structure:

• Nikto (one of the many server vulnerabilities Nikto can discover)
• Wikto

To check for SQL Injection vulnerabilities:

• WebInspect from HP
• Scrawlr a free alternative from HP
• W3AF
• Gamja
• Acunetix Web Vulnerability Scanner. Manual, FAQ
• Tip/Trick: Guard Against SQL Injection Attacks
• sqlmap
• SQL Injection Prevention Cheatsheet by OWASP
• SQL Injection attack used in breach of 168,000 Netherlands travelers

To check for Cross-site scripting (XSS) vulnerabilities:

Cross-site scripting (XSS) is a client attack. If a web application accepts text (such as the following) into a field and (by presenting the entered data to the client) produces an alert on the client, then the web application can be used to attack the client.

alert("Vulnerable to XSS");

Typical reflected XSS example: a URL containing a script. The script does not reside on the server.

Typical stored XSS example: script included in data entered or uploaded. The script does reside on the server.

A more interesting attack would be an iframe which opens a link to an untrustworthy web page. The assumption that the web application is making: data entered into this field is the data I am expecting to see (also referred to as “valid data”).

• CORE Security Technologies
• Gamja
• Acunetix Web Vulnerability Scanner, Manual, FAQ

The demo version allows you to scan any web site, operated by you, for Cross Site Scripting Vulnerabilities. Acunetix WVS will report the vulnerabilities’ location and will suggest techniques to fix them. Note that this edition does not allow saving of the reports.

The demo version you can also test all aspects of the product (including scanning for SQL Injection, Google hacking, and directory traversal attacks) against these Acunetix test sites:
http://testphp.acunetix.com
http://testasp.acunetix.com
http://testaspnet.acunetix.com

• XSSploit
• Cross Site Scripting cheatsheet from ha.ckers.org
• XSS (Cross Site Scripting) Prevention Cheatsheet by OWASP

Host user-uploaded content on a separate domain (e.g. usercontent.example.com). Any script in the user-uploaded content won’t have access to content in your application domain.

• DOMinator is Firefox-based software for analysis and identification of DOM based Cross Site Scripting issues (DOMXss or “type-0 XSS”). (blog)

To check for Cross-Site Request Forgery:

Cross-Site Request Forgery (CSRF) is a client attack tricking a user into submitting a request. Tricking a person into clicking a link while they are logged into an application (such as electronic banking) and thereby submitting an unintended (“forged”) request would be an example of a CSRF attack. The assumption that the web application is making: the transaction was submitted by the application user, and not by a third party which is riding the application user’s session. Same origin policy enforcement at the client side would prevent CSRF attacks, but the web application cannot assume that same origin policy is enforced. A CSRF attack can be difficult to prevent. You must inspect the business logic, and not simply scan for input. You can expect any “Are you sure?” measures, which are intended to alert the user when an unintended server interaction is suspected, to be ineffective. You can expect the user to choose the “Yes” option without reading the text. More elaborate measures (such as Captcha codes) will slow down the user in hopes of more informed decisions. The OWASP CSRFGuard Project attempts to address the issue of request integrity through the use of unique request tokens. See also PaulDotCom Episode 214 for Cross Site Request Forgery scanning with Pinata. (Something known as MonkeyFist is also intended to help discovery CSRF vulnerabilities.) See Michael Brooks’ DEFCON presentation “CSRF Bouncing” [pdf].

To check for Cross-site tracing (XST):

If a Web server supports the TRACE method, an attacker can craft a special HTTP request that bounces malicious scripts into a victim’s browser, resulting in an XST attack. You do not need the TRACE method in production environments.

• Either disable or block the TRACE method.
• In Apache, use mod_rewrite.
• In IIS, use UrlScan.

To check for JavaScript errors:

By default, Internet Explore does not notify the user about JavaScript errors. When testing your own web site, choose ‘Internet Options’ on the Advanced tab. Uncheck ‘Disable script debugging’.

To check for SWF errors:

• Review Flash applications with HP’s SwfScan (functionality is in HP’s WebInspect).
• See the blog from Peleus Uhley of Adobe regarding Creating more secure SWF web applications. Updated to include changes made in Flash Player 10.
• IBM has a site (demo.testfire.net/vulnerable.swf) which illustrates Flash vulnerabilities (Cross-Site Flashing Examples); read IBM’s Flash Parameter Injection whitepaper and HP’s Blinded by Flash Solving the widespread security risks Flash developers currently can’t see that threaten enterprise data.
• FlashFirebug – Debug ANY AS3 SWF files on the web. Edit properties and inspect elements. Redirect SWF output to the extension. Run AS3 code and transform objects on the fly. Access SWF assets with the decompiler. View AMF calls and Shared Objects and much more!

The role and limitations of automated testing

Automation can be used to identify vulnerabilities of the following Technical Attack types:

• Command Execution
• Buffer Overflow
• Format String Attack
• LDAP Injection
• OS Commanding
• SQL Injection
• SSI Injection
• XPathInjection
• Information Disclosure
• Directory Indexing
• Information Leakage
• Path Traversal
• Predictable Resource Location
• Client-Side
• Content Spoofing
• Cross-site Scripting
• HTTP Response Splitting

You will need people to identify the following non-technical, business logic vulnerabilities:

• Authentication
• Brute Force
• Insufficient Authentication
• Weak Password Recovery Validation
• Cross-site Request Forgery (CSRF)
• Authorization
• Credential/Session Prediction
• Insufficient Authorization
• Insufficient Session Expiration
• Session Fixation
• Logical Attacks
• Abuse of Functionality
• Denial of Service
• Insufficient Anti-automation
• Insufficient Process Validation

PDF Files

See Didier Stevens PDF Tools when examining a PDF file for malware. Avoid rendering a suspicious PDF file.

See his InfoSec Handlers Diary Blog “Encrypted PDFs” for decrypting PDFs.

 

Disable, or plan to disable, SMBv1

SMBv1 is s deprecated protocol, replaced by SMBv2 and SMBv3.

A vulnerability in SMBv1, which was patched in MS17-010, has been exploited by Petya ransomware to propagate itself within a network. Another vulnerability in SMBv1 can crash a server. Microsoft will not be patching this vulnerability.

https://threatpost.com/windows-smb-zero-day-to-be-disclosed-during-def-con/126927/

Learn if you have a dependency upon SMBv1. Windows prior to Vista (including Windows XP) requires SMBv1. A variety of third party products use SMBv1:

https://blogs.technet.microsoft.com/filecab/2017/06/01/smb1-product-clearinghouse/

Manage SMBv1 using group policies. While a registry modification would work, you want group policy to enforce the change on any systems which may have been missed, any new systems, and any unsupported maintenance.

https://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and-windows

Additional products may be discovered when Microsoft disables SMBv1 by default on new builds of Windows 10.

https://www.bleepingcomputer.com/news/microsoft/microsoft-to-disable-smbv1-in-windows-starting-this-fall/

Disable LLMNR and NBT-NS

Link-Local Multicast Name Resolution (LLMNR) (UDP/5355)

Netbios Name Service (NBT-NS) (UDP/137)

LLMNR and NBT-NS are unnecessary Windows protocols and therefore unnecessary Windows attack surfaces.

LLMNR and NBT-NS are local subnet broadcast name resolution mechanisms. If DNS is working, you don’t need these protocols. If DNS isn’t working, fix it. Since they are local subnet mechanisms they are not scalable. There is no reason to fall back upon these protocols. You would not want to learn that you were relying upon these protocols.

Additionally, there are malware kits which exploit these protocols to capture user credentials (a compromised machine on the subnet responds to a name resolution request and receives user name and the NTLMv2 hash of the credentials; use Jack the Ripper and you have the password).

How do you disable LLMNR and NBT-NS? You want to use group policies. While a registry modification would work, you want group policy to enforce the change on any systems which may have been missed, any new systems, and any unsupported maintenance.

https://www.sternsecurity.com/blog/local-network-attacks-llmnr-and-nbt-ns-poisoning

http://blog.westmonroepartners.com/secure-nbt-ns-poisoning-attacks/

There is a feature that will stop working when LLMNR is disabled: ad hoc networking will fail.

https://blogs.technet.microsoft.com/networking/2008/04/01/how-to-benefit-from-link-local-multicast-name-resolution/

 

 

Ending unsolicited email (SPAM)

See also: the Identifying Phishing blog post at MxToolbox

The traditional email acceptance model is to accept email unless you have a reason to reject it. Trust, unless there is a reason not to. The spammer sends emails; recipients complain and filters are adjusted to block the current batch. The spammer makes changes that avoid the filters, and the cycle continues.

One such filter is sender’s IP address. Blocking email by sender IP address is a maintenance burden made worse by IPv6.

The model needs to change to one that accepts only those sources where there is a reason to trust. The solution must extend the current email mechanisms when adding a trust mechanism.

Part of the solution is for the sender to implement a Sender Policy Framework (SPF) text record in the Domain Name System (DNS). The SPF record lists which IP addresses are permitted to email on behalf of the domain. The recipient’s email server (Mail Transfer Agent or MTA) can compare the sending IP address with those listed in the DNS. The MTA can make informed decisions about whether to accept the email without requiring maintenance.

A DomainKeys Identified Mail (DKIM) text record in the DNS enables the sending organization the sign messages. The DKIM record contains a public key from a asymmetric RSA key pair. The recipient’s MTA can verify that the message was sent by the organization which claims to have sent it.

A Domain-based Message Authentication, Reporting & Conformance (DMARC) text record in the DNS indicates the recommended disposition of an email which fails SPF source verification or DKIM authentication. The recipient MTA could be advised to accept the email, accept the email as spam, or reject the email.

Responsible mail senders are advised to implement SPF, DKIM, and DMARC quickly. Email recipients will want a no-maintenance method for disposing of spam.

https://blogs.msdn.microsoft.com/tzink/2016/02/19/common-errors-in-spf-records/

My Web Site Was Hacked?

If someone may be using your site to participate in a DDoS attack, it may be due to a configuration error. You may want to see what ports you have open.

http://www.t1shopper.com/tools/port-scan/

Is someone using you to perform a denial of service attack on someone else? It is not just an annoyance to someone else, it also uses bandwidth that costs you money.

Test for misconfigured NTP server (UDP port 123)

http://openntpproject.org/

Test for open recursive DNS resolver (UDP port 53)

http://www.openresolver.com/

If chargen (port 19) is found, disable it. This antiquated service is of no use to you and can be used to attack others.

If LDAP (port 389) is found, determine if exposing your email server is necessary. Best practices say it is not. If your mail server must be exposed to the Internet, make sure UDP port 389 (connectionless LDAP or CLDAP) is not exposed to the Internet. This service can be used to attack others.

That list is UDP ports 19, 53, 123 and 389.

About participating in WordPress Pingback DDoS attacks

https://isc.sans.edu//forums/diary/Wordpress+Pingback+DDoS+Attacks/17801

http://fooplugins.com/prevent-wordpress-pingback-ddos/

Is someone using you to send spam? Test for an open SMTP mail relay (port 25)

http://www.mailradar.com/openrelay/

The above attacks (NTP, DNS, Chargen, and WordPress Pingback DDoS attacks, as well as using you to send spam) do not indicate that you have lost information or that a virus has infected your system. They indicate that someone is taking advantage of a misconfiguration to use your site for their own purposes and make it look like you are responsible.

On the other hand, you can loose information and host viruses through other misconfiguration choices. PHP-based web sites (using Joomla, WordPress or Drupal for example) are often compromised through vulnerable plugins. For examples and corrective measures, see C99Shell not dead.

WordPress best practices https://bestvpn.org/bloggers-guide-to-wordpress-security/

WordPress Security Scan‍ https://hackertarget.com/wordpress-security-scan/
wpscan‍ https://wpscan.org/
WPscans‍ https://wpscans.com/
Web Shell Detector http://www.shelldetector.com/
PHP-Shell-Detector https://github.com/emposha/PHP-Shell-Detector
PHP-backdoor-detector https://github.com/yassineaddi/PHP-backdoor-detector

OWASP Top 10

Use the OWASP Application Security Verification Standard. Do not limit your focus to the OWASP Top 10 Vulnerabilities.

SQL Injection (SQLi)

Problem: Malicious user input is interpreted as a database query.

Cause: The malicious user input has had inadequate data validation by the web tier.

Detection: If you have the application tier source code, review it. If you don’t, mechanically test through the web tier (e.g., sqlmap).

Mitigation: Parametrize queries in the application; that is, use variables in prepared SQL statements. Never construct queries by concatenating user input. If you don’t have access to the application source code, use an already available known and proven HTML sanitizer. SQL Injection can be mitigated with a Web Application Firewall.

See Secure Web Application Development

• Use Parameterized APIs for Data Access
• Use Positive Input Validation
• Avoid Using Command Interpreters
• Escape Special Characters, If Parameterized APIs Are Not Available

https://www.owasp.org/index.php/Top_10_2010-A1
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet

Cross-site Scripting (XSS)

Problem: Malicious user input is displayed on a web page. The user’s web browser processes the malicious input, attacking themselves. The user shot themselves, but didn’t know they were holding a gun.

Cause: The malicious user input has had inadequate data validation by the web tier.

Detection: If you have the application tier source code, see the OWASP Code Review Guide article on Reviewing code for Cross-site scripting Vulnerabilities.  If you don’t, then the Browser Exploitation Framework (BeEF), XSS Cheat Sheet, burp and manual tests would be a start.

Mitigation: Use safe re-encoding of the user input before it is displayed on a web page. Use an already available known and proven encoder such as OWASP ESAPI. Input validation is often used, but displaying content in a safe manner is to be preferred. Cross-site scripting can be mitigated with a Web Application Firewall.

• Escape All Untrusted Data in HTML Contexts
• Use Positive Input Validation

https://www.owasp.org/index.php/Top_10_2010-A2
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

Session Hijacking

Problem: In order to maintain a conversation, a web application needs to keep track of where it left off. The web application needs to preserve a session’s state. A person can impersonate a web application’s state, the web application can take incorrect actions.

Cause: Session tokens (how you maintain state in web applications) are passed in clear text.

Detection: Review packet captures for tokens passed in clear text.

Mitigation: Encrypt communication using HTTPS. Additionally, use session inactivity timeouts.

• Centralize Authentication and Session Management Controls
• Protect Session IDs from XSS

https://www.owasp.org/index.php/Top_10_2010-A3
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

Parameter Manipulation (Insecure Direct Object References)

Cause: User supplies a value in the URL and the application accepts it.

Detection: Review packet captures for URL parameters.

Mitigation: If you have access to the application, server-side validation should be used. Is the returned value acceptable? Are there errors in business logic? Additionally, use session parameters (where the data elements are stored on the server side and accessed through the session identifier) instead of URL parameters (which are exposed on the client side). If you don’t have access to the application … a web application firewall can help sanitize input, but cannot prevent that input from being modified and cannot fix errors in business logic.

• Use Per-User or Per-Session Indirect Object References
• [OR] Check Access Control Permissions Whenever Performing Direct Object References
• Disable Directory Browsing

https://www.owasp.org/index.php/Top_10_2010-A4

Cross-site Request Forgery (CSRF)

Problem: The user establishes an authenticated session. The user then connects to an unrelated site. The unrelated site takes advantage of the user’s authenticated session to perform actions.

Cause: The user’s intended web application supports URLs which can specify complete session information using parameters. The unrelated site performs the unauthorized action through a crafted URL. The URL requires no user interaction, or minimal interaction.

Detection: Review web application for URL parameters. Review packet captures for URL parameters.

Mitigation: If you have access to the application, implement CSRF session tokens (for each page a new token is created and hidden on the user’s web page; the server checks the next transaction for the predetermined token). Session timeouts would limit the availability of authenticated sessions. Re-authentication before the transaction is completed would require user interaction.

• Include Unique Tokens in HTTP Requests

https://www.owasp.org/index.php/Top_10_2010-A5
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet

CSRF Proof of Concept with OWASP ZAP

ASP.NET: The anti-forgery token can be used to help protect your application against cross-site request forgery. To use this feature, call the AntiForgeryToken method from a form and add the ValidateAntiForgeryTokenAttribute attribute to the action method that you want to protect.

Security Misconfiguration (Insecure Configuration)

Cause: Insufficient hardening. Lack of configuration management process. Lack of account management process. Lack of patch management process. Security patches not installed, unnecessary services enabled, default passwords, excessive permissions

Detection:

Mitigation: Repeatable hardening process. Recurring inventory and audits.

• Establish A Repeatable Hardening Process
• Keep Up with Security Updates
• Design a Strong Application Architecture
• Run Scans and Perform Audits

https://www.owasp.org/index.php/Top_10_2010-A6
https://www.owasp.org/index.php/Security_Architecture_Cheat_Sheet

Insecure Cryptographic Storage

Cause: Sensitive information is stored or transmitted in an insecure manner. The cryptographic method may be obsolete or the implementation may be weak.

Detection:

Mitigation: There may be specific regulatory requirements to consider. Review information to determine if it is sensitive and if it should be stored. (Classify assets, model realistic weaknesses, determine threats which may exploit those weaknesses, implement defenses.) Use known, strong encryption methods, long keys and a key management system.

• Consider the Threats You Plan to Protect Data from
• Encrypt Off-site Backups
• Ensure Strong Algorithms Are Used
• Hash and Salt Passwords
• Protect Keys and Passwords

https://www.owasp.org/index.php/Top_10_2010-A7
https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet

Failure to Restrict URL Access (Forced Browsing)

Cause: Incorrect web server configuration. Insufficient restrictions in application logic. User can guess a URL that  provides access to information or processes that should be restricted.

Detection: Crawl the application for page access. Should these pages be exposed? Test exposed pages for insufficient authorization enforcement.

Mitigation: Authorization checks within the application. Page level authorization at the web server. Can be mitigated with a Web Application Firewall.

• Require Authentication and Authorization for Each Sensitive Page
• Use Role-based Authentication and Authorization
• Make Authentication and Authorization Policies Configurable
• Deny All Access by Default

https://www.owasp.org/index.php/Top_10_2010-A8

Insufficient Transport Layer Protection (Clear-text Communication, Cookie Poisoning)

Cause: Sensitive information is sent unencrypted. This could include unencrypted session cookies which, if exposed, can be used to impersonate the authenticated user (capture their session).

Detection: Review packet captures for sensitive information passed in clear text.

Mitigation: Implement “always on” SSL (HTTPS) with strong keys (greater then 128 bit ciphers) and disable weaker protocols (SSLv1, SSLv2, SSLv3). Implement a key management policy. Alternately, encrypt the sensitive information (such as cookies) and sign it (so it cannot be modified). Consider disabling HTTP if the site is sensitive. Can be mitigated with a Web Application Firewall.

• Enable SSL
• Use SSL for All Sensitive Pages
• Set the Secure Flag on All Sensitive Cookies
• Use Only Strong SSL Algorithms
• Use Valid SSL Certificates
• Secure Backend Connections

https://www.owasp.org/index.php/Top_10_2010-A9
https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

Unvalidated Redirects and Forwards (Unchecked Redirects)

Cause: Lack of validation when using forms or parameters to forward or redirect users. This enables hackers to use your site as a trusted name or domain when redirecting to their malicious site.

Detection:

Mitigation: Don’t use parameters to forward or redirect users. Use session information stored on the server. Alternately, whitelist the URLs that the user can be forwarded to and verify that the user has authority to access the web page.

• Don’t Use Redirects or Forwards, If Possible
• Don’t Use User Input for Calculating Destinations of Redirects or Forwards
• Use Mapping Values When Calculating Destinations of Redirects or Forwards

https://www.owasp.org/index.php/Top_10_2010-A10

Security Awareness Training

Security Awareness Training Framework Wiki

Measuring Human Risk: What is Your Organization’s Security Score? The methodology and results of a multi-year human security risk assessment and security awareness initiative at Michigan Technological University.

This presentation covers effective security awareness training and measuring its effectiveness. When I was doing security awareness training it was largely saying the same thing as last time, expecting a different result. Additional ideas were always appreciated. This presentation is worth listening to and the handout contains useful information.

Securing The Human in EMEA – Next Generation Awareness Programs

SecuringTheHuman.org

Confidentiality – only authorized / appropriate persons have access to the particular information

Integrity – accurate and adequately complete information

Availability – all authorized persons have access as needed

Accountability – actions cannot be repudiated

Authentication – validate the agent

Authorization – control which agents can access which assets

Accounting – determine which agents access which assets and what they did there

Property	Threat
Authentication	Spoofing
Integrity	Tampering
Non-Repudiation	Repudiation
Confidentiality	Disclosure
Availability	Denial of Service
Authorization	Elevation of Privilege

WASC Threat Classification

OWASP Application Security Verification Standard 2009 (pdf)

New hire initial assessment

You’ve just been hired and Information Security is now your responsibility.

Who has immediate concerns?

Introduce yourself and ask what most concerns them. Get their names. This is for your use only. Try to remember their names. Can you take a photograph?

Assessment

NIST Special Publication 800-115: Technical Guide to Information Security Testing and Assessment [pdf]

What company policies and regulatory requirements exist? What compliance programs (SOX, PCI, HIPAA, SSAE 16) must be observed?

Individual Products

The National Checklist Program (NCP), defined by the NIST SP 800-70 Rev. 2, is the U.S. government repository of publicly available security checklists (or benchmarks) that provide detailed low level guidance on setting the security configuration of operating systems and applications. NCP is migrating its repository of checklists to conform to the Security Content Automation Protocol (SCAP). SCAP enables standards based security tools to automatically perform configuration checking using NCP checklists. For more information relating to the NCP please visit the information page or the glossary of terms.

Risk Assessment

The SANS 20 Critical Controls

• When doing the inventory of authorized and unauthorized software. include software composition analysis. What libraries are being used? Do these libraries have vulnerabilities?

The California Department of Technology Risk Assessment Toolkit has links to great resources.

Prioritize Tasks

What gaps do you you fill first?

There will always be risk. What level of risk is acceptable?

Review

Check your work. Repeat.