Welcome to the extraxi blog...

If you found this page accidentally and don't know what extraxi is about... we specialise in reporting solutions for the Cisco Secure ACS and Funk SBR access control servers (aka AAA servers).

The servers are predominantly used to secure network services such as dial, wireless lan, vpn, firewall and network device management.

Typically these servers just chuck out MBs of raw CSV log data about network activity. What we do is to help collect this data then import and turn it into useable information.

Thursday, 22 April 2010

How to survive an ACS audit with aaa-reports!

For many organisations the Cisco Secure ACS server is the guardian of the network - controlling administrative access to routers and switches plus overseeing end network users over VPN, wireless and firewall.

Its no surprise therefore that it should come under intense scrutiny during an audit. Perhaps what is surprising is the lack on awareness over best practice for running ACS in a secure way. We'd like to help in our small way and below is a list of tips we've picked up over the years of providing reporting services for ACS.
  1. Buy aaa-reports! Without the ability to aggregate the logs from all your ACS servers and report on the data, or use our query builder for forensic analysis, or import the ACS database to document the policy features enabled.... you'll have a hard time getting the evidence that an auditor might ask for.
  2. Make sure ACS is logging the appropriate attributes for the reports you need to create. For example if you need to document who did what to devices in specific Network Device Groups (NDG) you must ensure this value actually gets logged. Performing ACS upgrades often sets logging configs back to their defaults.
  3. Create a build specification for your ACS. Detail the "meta config" of your ACS so that after an emergency hardware swap-out or software upgrade you can quickly check that the ACS has the correct configuration. The build spec document should be under version control and is a useful item in itself to convince an auditor your system is well controlled.
  4. Create a Change Control system for config changes on the ACS. Since its ACS that decides who gets access and what commands they run on your network its vital you report on the Administration Audit logs. During an audit you can then correlate entries in your change control system with actual edits recorded in the Admin Audit logs. aaa-reports! can document what all or individual ACS admins did in detail.
  5. Retain 2 years of actual CSV log data on your reporting server. For general day-to-day reporting you dont need this amount, but during an audit you may be required to show what happened on a specific historic data. aaa-reports! multi-db feature will allow you to create a specific back-end database just for this task and import logs from the required time period. Alternatively use the aaa-reports! snapshot feature to regularly save its database state, for example quarterly. You may then connect aaa-reports! to any of the historic snapshot databases to report on the data from that quarter.
  6. Regularly export the ACS database into aaa-reports! If you are running reports against log data from 2 years ago you also need to know what was in the ACS database at the same time - using a more recent ACS database might yield unexpected results because the configuration is likely to changed in the meantime. Use csvsync to regularly grab the ACS database and keep them alongside the retained CSV logs for future reference.
  7. Review the quality of ACS log data. From time to time its worth taking a look at the quality of the data getting logged. We often find customers with rogue scripts being automated on devices that cause the ACS Failed Attempts logs to become full of many MBs of "junk data" - essentially one failed attempt for each line of the script. If left to continue for months the real data starts to become more difficult to find.
In terms of specific questions that an audit will concentrate on, typically it will revolve around demonstrating that not only is there specific and adequate policy to control access to those parts of the network require it, but also to seek evidence that those policies are in fact working. In aaa-reports! we added a whole set of reports for TACACS+ Device Administration (TDA) that attempt to document the ACS policy configuration, answer questions such as "who can/cannot access devices and once connected what can they do?" and finally report on what did actually happen.

Below are some additional TDA specific tips:
  1. Ensure services such as shell/exec are only enabled for ACS groups that really need it. The aaa-reports! TDA Group Summary report will list every ACS group and what TDA features are enabled. The TDA Group Detail report can be used to inspect the policy in detail.
  2. Check for user-level ovverides. In general users should always inherit policy from their group unless there is good reason. The aaa-reports! TDA User Summary report list users with group overriden configuration. The TDA User Detail report can be used to inspect what policy items are specific to the user.
  3. Use Network Access Restrictions (NAR) to prevent login by unauthorised personnel. The first line of defence is to only allow device admin users access to routers and switches. We find some customers rely purely on command authorisation - this potentially lets anyone access the device who can authenticate. Imagine the scenario where ACS has "unknown authentication" enabled pointing at your Windows AD then answer "Who has access?". aaa-reports! can report group-by-group on device access controlled by NARs and therefore answer "Who has access to device XYZ?"
  4. Use Device Command Sets (DCS) for command authorisation. Create a set of re-usable DCSs with meaningful names in preference to simple group-level command authorisations. ACS administration is simplified and the auditor should understand what the intent of the policy is by its name. aaa-reports! can document the both the content of each DCS and the group assignments, thereby answering the question "What commands can user X execute on device XYZ?"
  5. Seek out and remove old ACS user accounts. aaa-reports! can report on inactive users both from examination of accounting logs and (if password aging is enabled) from the imported ACS database itself.
  6. Learn how to use the aaa-reports! Query Builder. Despite the comprehensive set of pre-built canned reports, during an audit you are likely to be asked questions about a specific date, user or device. Knowing how to use the QB to build filter/sort and group/totalling queries will get the answers quickly. Take the random question "How many sessions did user X have on devices A, B and C on this date?" The aaa-reports! QB can easily create custom reports that filter on any number of attribute values, group by multiple columns and have calculated fields such as sum, count, average etc. If you have a working knowledge of Visual Basic 6 (VB6) its also possible to use a rich array of formatting and other VB6 functions to create additional fields.
Undergoing an audit is never easy, but at least with the right tools it doesnt have to be awful!

No comments: