Simple Sanity Checks

We all know that security testing is important, and many assessments can be extensive. The good news is there are some easy checks that IT and information security staff can do just to make sure things are working as expected. Verifying the results of previous assessments can serve as an abbreviated version of a documented test. Quick and easy checks like the examples below only take a few minutes and makes it easy to schedule them more frequently. They can especially be helpful before an audit or an exam. Protip: Talk to your security staff before doing any testing, so they know that any relevant flags or alerts that pop up on their end are expected.

• Web content filtering: If you know what web categories are supposed to be blocked on your network, take a few minutes to try to access a few of those types of websites. Common examples to test are public webmail and file sharing sites. If access is blocked normally – great! If not, you may have uncovered a problem that might not have been caught until your next audit. Do yourself a favor and DON’T test any unpleasant sites, as those attempts may be logged by the filtering system.
• USB restrictions: If you know that access to USB drives is supposed to be restricted, this can also be tested very quickly by simply plugging in a known good USB stick. Consider using a new USB stick to test with for best protection.
• Email encryption: If certain keywords or strings of characters (like account numbers or Social Security Numbers) are supposed to automatically fire off the email encryption system, consider sending a test email to a controlled account outside of your email system with one or two of those factors in the email. Don’t use actual account numbers or SSN’s; the format of the number string should be enough to tell the system to encrypt the email. Also, you might need to check that test account from your smartphone, since public webmail should be blocked on the corporate LAN.
• Multifactor authentication (MFA): Most organizations are using MFA to control access to at least some resources. Device profiling factors (like browser cookies for example) can reduce the amount of MFA requests to users – but it can also mask potential issues with MFA. Consider logging into an MFA-controlled resource from a different system that you normally use, or from a private browser session, or take the plunge and clear cookies from your browser and see if you get the expected MFA prompt. This is also a great way to test MFA on systems that you may not use frequently.
• Physical access: Many organizations control physical access using keycards or keyfobs. If you know that your card is not supposed to work for a certain area, a quick swipe can validate that the expected restrictions are working. It really would be best to coordinate this with relevant parties beforehand.

Think about your organization’s environment – you may have a couple other items that come to mind that you want to check so you can sleep a little bit better tonight.

Authored by: David Bentley, CISSP