1. They provide a standardized, industry-agreed way to secure Linux servers.
2. Yes, it does.
3. A level 1 benchmark is not expected to have an impact on day-to-day operations of your server. A level 2 benchmark is and so should be implemented with care.
4. Scored benchmarks are expected to be crucial to all systems, whereas benchmarks that are not scored are expected to be applied to only some systems (for example, wireless network adapter configuration hardening will only apply to a subset of machines—hence, this should not affect the score of all machines).
5. This is normally provided in the benchmark document but often involves using the grep utility within the script to check for the configuration settings in a given file and reporting back on whether it was found or not.
6. Possible answers include the following:
   • Pattern matching can be an imprecise science, and you must be careful of false positives and indeed false negatives!
   • Shell scripts are not normally state-aware and care must be taken not to write the same configuration out each time the script is run, even if it is the same as before.
   • Shell scripts are difficult to read, especially when they become large, and so can be difficult to manage and maintain.
7. Shell scripts are not very readable, and as the number of security requirements to implement increases, so does the size of the script, in the end becoming something that no-one would be able to manage.
8. Pipe the shell script into an SSH session opened with the remote server.
9. This enables the path to be altered easily in case the script needs to be repurposed—for example, some key system binaries live in different paths on Ubuntu and CentOS systems.
10. In general, it is best to run scripts at the lowest privilege level possible, only elevating for specific tasks that require this. Also, sudo is sometimes configured to require a Terminal session, and this can prevent running an entire script under sudo when you pipe it into an SSH session.