Shared Security Services
L&I, like most organizations, has implemented security separately for each of its applications. The more applications you get, the more redundancy is introduced, and the more likely it is that you are inconsistently applying the law and your own internal policy.
We began this project with an exercise we called the “exegesis.” In this case it was an exegesis of all the laws, regulations and policies that applied to data security within the Department. In addition to a lot of reading and excerpting, this required semantic analysis, as each of the laws had a different aspect. Some of the laws (such as HIPAA) discuss patients’ rights. A special subclass of workers, injured workers who have been treated by medical professionals, are patients under this definition. There were dozens of such nuanced distinctions.
From this we constructed a set of rules that needed to be implemented in order for the applications to comply. This was also at a time when the State was beginning to open up its system to the general constituency, and therefore the number of users was about to go from 3,000 mostly internal users to up to 3,000,000 total users (workers, employers, and providers in the State).
We built a set of requirements and brought in all the usual security software suspects. At the time, the business models of these companies did not allow them to separate Authentication from Authorization (they priced their products based on number of authenticated users). However, the State was mandating the use of its own Authentication service. We found no vendor who could solve the Authorization requirements we had without including a redundant Authentication service. While we were disappointed, one of the analysts on this project was elated. “In the past we would have selected one anyway and dealt with the fact that couldn’t handle our requirements separately.”
As a result of our findings, we designed a custom shared security service, which was then let to an implementation company in a competitive bid. In our original design the service would have relied on a rules engine to evaluate the authorization rules. Perhaps because we had done such a good job on the exegesis and significantly reduced the number of rules, the implementation team hard coded the rules. The service has been in use for over five years; all new applications use it, and existing systems are being retrofitted to it.
