
I wrote my personal note on security descriptions in ACS spec. This might be too primitive, but in case we lost where we start. Mybe after the presentation by security expert... -Keisuke Michael Behrens wrote:
I also spoke with a security guru today about talking with us about network PKI based protocols. He's available, however I'm still waiting for a "definite" confirmation from him. I also will draft up some general information which might help us navigate through the various standards.
I'm looking forward to next week!
See you there! Notes on security descriptions in ACS spec. The requirements and capabilities in security area extends to broad range. They include but not limited to: IDENTIFICATION, AUTHENTICATION, AUTHORIZATION, CONFIDENTIALITY, DATA INTEGRITY, AUDIT, DATA DISPOSAL, SYSTEM INTEGRITY. Not all of these need to be specified by the ACS specification nor can be achieved only by the ACS. Rather, many should be specified in system wide and designed as a system so that system fulfill the requirements throughout the lifecycle of whole use case. Having a security service inside a system and let it control, monitor and provide with the common capability to the services in a system would be a good idea can cover most of them in one place. Nevertheless, some of these specification or requirements might be better considered per each service, since those may results in more appropriate or effective requirement analysis. Also, presenting a recommendation among the options and/or defining the minimum set of the requirements would be worth. One example is the signing mechanism that ensures the data integrity for the Application Archive Format. It can detect unexpected modifications of the archive, in case that unwanted third party made alteration to the archive. There can be multiple relevant technologies to implement it. To archive the maximum interoperability between implementations it might better to have smaller number of standard ways. If we are sure which is the best suitable one, we can recommend one or require it. On the other hand, we might leave it to system designers and/or wait till the de facto standard is established. All that depends on how much we are sure if it is correct. Anyway, we need at least find and define the minimum set of the requirements. And we cannot simply include all specifications in the security area. The specification should define what is the minimum requirements to maintain the data integrity for the AAF. Appendix A. Summarized overview of the security criteria The Master Security Criteria V.3 summarizes these as below: Identification Identification is the process of recognizing a user's unambiguous and auditable identity with the help of an identifier that is typically referred to as the user-ID. In general, the user-ID need not be confidential. It is the unambiguous name of a user through which the user can be held accountable. As such, all actions initiated by a user need to be associated with the corresponding user-ID. Authentication Authentication is the process of verifying the claimed identity of a user. Depending on the system and the application, different kinds of authenticators can include passwords, tokens, smart cards, key-based authenticators, voice recognition, and/or a retina scan. Regardless of what type is used, it is critically important to minimize the compromise of an authenticator. Authorization The authorization feature is focused on the controls associated with establishment of a session with the system, invocation of operations- or services-oriented tasks, or the access of information while it is stored. Confidentiality The confidentiality protection feature is focused on protecting sensitive information from unauthorized disclosure while the information is being generated, stored, manipulated or forwarded. Data Integrity This feature is focused on preventing and detecting unauthorized modification of data that is associated with a user, the system itself, or the communications path. Audit This feature has to provide adequate capabilities to investigate unauthorized activities after an event, so that the proper remedial action can be taken. This implies the recording of security-relevant events into an audit log that can be analyzed by the administrator. Data Disposal This feature is focused on protecting sensitive information from unauthorized recovery and subsequent disclosure from internal system memory and storage after authorized use. System Integrity This feature is focused on the functional integrity of the system, including the controlled creation, installation and operation of the system software and data.