WhiteHat Sentinel Service – How it all Works
WhiteHat Sentinel is a subscription-based service assuring complete website vulnerability management that is client-controlled and expert-managed. Unlike traditional website scanning software or consultants, WhiteHat Sentinel is the only solution to combine proprietary scanning technology with custom testing by a team of leading security professionals. Below is an overview of how the Sentinel Service typically works.
1. Client provides a list of URLs representing websites to be tested by the WhiteHat Sentinel Service. This is defined in the service contract, and future URL changes require contract addendums.
2. The WhiteHat Security Operations Team begins configuring Sentinel to monitor and test the websites residing at the specified URLs.
- Note: If the websites use Internet Explorer proprietary JavaScript (from Visual Studio) or ActiveX controls, custom coding may be required on WhiteHat’s part to scan the websites.
3. If user credentials are required to access the websites, and WhiteHat Security Operations cannot self-signup, a pair of user credentials for those specific websites will need to be supplied. If a website has multiple roles, a pair of users for each role in the website will be required (e.g., user, supervisor, admin, etc.).
- Note: The more users and roles provided, the more testing work is created for WhiteHat Sentinel. This increase will likely be at least linear, if not exponential. If it takes 24 hours to test a website with one pair of users, adding four pairs of users will increase this to a minimum of 96 hours, plus additional Operations Team time to consolidate duplicate findings. WhiteHat is developing new technology to handle these in parallel and consolidate results. Until then, increasing number of credentials significantly increases workload and delivery timelines.
4. The client controls everything Sentinel does – start times, stop times, scheduling, retesting – all managed through the WhiteHat Sentinel Interface. Initially, the Security Operations Team will assist the client in setting up time schedules and the authorization of the live testing. Once the times and dates are confirmed and credentials are provided, Security Operations does the rest. Vulnerabilities that are detected are rated on both severity and threat levels. This allows developers to best prioritize the remediation process.
- Note: The WhiteHat Sentinel Service is not a “scanner”. A “scan” does not represent the type of work unit that “scan” may imply from experience with network security scanners. WhiteHat Sentinel Service looks for undiscovered and unknown website vulnerabilities within distinctive and unique Web applications; network vulnerability scanners look for known vulnerabilities within known code. This is a vastly easier and well-defined process: Identifying a software version number and searching a database of known vulnerabilities for relevant issues. Website vulnerability management doesn’t have the luxury of version numbers or an available, exhaustive Web application vulnerability database; this makes website security significantly more complex.
As a result, website scanning is an iterative process by which WhiteHat Sentinel slowly and carefully discovers the website by digging deeper into the business logic, and making decisions about how to fill out and test forms (if it is safe to do so), and any custom tests that the Security Operations Team needs to write.
5. The Sentinel Service begins once the scanning process is activated. But remember, the scanning process is just the first step in an in-depth cycle. WhiteHat Sentinel combines proprietary scanning technology with custom testing that is conducted by the WhiteHat Security Operations Team. The Service is one part automated testing and one part discovery of new code or interesting logic for Security Operations to inspect. Here are the series of tasks that go on during this initial service:
- Test user credentials (may need to add new users/roles to scan properly).
- Train WhiteHat Sentinel on the business logic and how to understand forms and fill them out, and how to complete the workflow.
- Describe “fuzzer” tests to iterate through integer values, then compare responses for different values.
- Write custom tests unique to the website, based upon manual review of the business logic.
- Request/response tuning for edge case/unique uses of rich media (e.g., Flash).
- Note: Form workflow often occurs in layers. If it takes four forms to complete a transaction, WhiteHat Sentinel will find the first form, and then Security Operations will train Sentinel how to interact with that form. The next time Sentinel scans the website, it will take those actions on the form, and only then find the next form. It could take four scans to find and train a set of business workflow that took four forms to complete a transaction.
- Note: A “scan” may take five hours. Fully testing the website could take five weeks. Example: if restricted scanning windows are defined – say, only on Sundays – and it takes four scans after the first scan to dig deep enough to discover and learn how to fill out all the forms and business logic, train our scanner, write custom tests, etc., and WhiteHat Sentinel only runs those iterative scans on Sunday, then it will be five weeks from start of service until the website is “fully” tested.
6. After the initial “training and testing” of the website, the Security Operations Team schedules a review to go over the findings and explain how they relate/map to software development practices and what remediation strategies work best for the client’s situation.
- Note: The WhiteHat Security Operations Team is focused entirely on tackling Web security issues. They are well versed in explaining the security implications of the software defects and how to fix them quickly, completely, and verifiably.
7. Once the review is complete, ongoing assessments of the website can be conducted at anytime, or anytime the websites change. Websites can be monitored via the Sentinel Interface and tests can run “on demand” with the click of a button:
- Automatic retest – After vulnerability is detected, an automatic retest occurs almost instantly. (The only case an automatic retest will not work is when WhiteHat’s authentication credentials are no longer valid).
- Manual retest requests – “Queues” a ticket for the WhiteHat Security Operations Team to review and possibly retest by hand. (Manual retest requests can take up to five business days to complete.)
- Scanning is scheduled through the Sentinel Interface. Sentinel scans the websites “low and slow”, much more slowly than less mature technologies. This is because Sentinel usually runs against large production websites. “Low and slow” won’t jeopardize denying service to users while a test is being performed
- Scanning new code – As the WhiteHat Sentinel Service discovers new forms and new business logic it generates tickets internally for Security Operations to review.