[ Pobierz całość w formacie PDF ]
.This also enables the information-security team to benefit fromall of the other advantages of a quality system, including standardized docu-ment control procedures and reviews by an independent third party.It is important, however, that the quality system supports theinformation-security process and not the other way around.One of theparadoxes associated with an increased awareness of quality issues is that inseeking to achieve better and more accurate documentation, we may actu-ally be reducing the benefit by overloading the intended audience.Docu-mentation that is never read or is not correctly updated does not add muchvalue to anyone.Auditors in particular should take note here one of theconsequences of performing audits on a system-by-system basis is that it isdifficult to keep track of scalability issues.Whereas it might be reasonable torequire detailed documentation for a particular platform, the same level ofdetail may not be achievable as a goal for all platforms.Processes are normally documented by decomposing them into theirconstituent procedures and describing the latter.Common sense is requiredwhen doing this in order to avoid unnecessary complexity, and it is essentialto be selective in deciding what gets documented.Organizations shoulddecide for themselves what level of documentation is required for controlledoperations, but this should represent a balance between the level of detail ofthe content and the amount of work required to maintain it.TLFeBOOK 36 Management techniquesIn some cases, the best approach may be to produce a minimal docu-mentation set.This both increases the probability that it will actually be readand used correctly and simplifies the maintenance process.When compilingthe documentation itself, consider the benefit of graphical techniques andchecklists as an alternative to normal text.This often makes the content eas-ier to understand for the target audience and reduces the volume of text.Similarly, using references to other documents also helps to reduce theamount of text, while ensuring that redundant information is kept to aminimum (redundant information should be avoided as updating it consis-tently is problematic).Again, where quality systems already exist, theyshould provide guidance on these issues.The process description and detailed procedures specify which activitiesare carried out and how.These documents, however, do not normally com-ment on the level of service that is to be provided to particular customers.Defining and agreeing on a level of service with customers (internal orexternal) is highly recommended, as it helps control user expectations andcan considerably reduce the pressure on the help desk or security adminis-trators by reducing unnecessary phone calls.Levels of service to be providedto particular customers are formalized using service level agreements(SLAs).Defining SLAs can be a lengthy process, particularly if the objectives ofthe exercise are too ambitious.As usual, to receive the benefits it is impor-tant to be pragmatic.Where internal SLAs are concerned, it is neither usefulnor productive to try to cover every possible scenario, and both partiesshould be prepared to be reasonable in interpreting the agreement once ithas been made.Without this flexibility, the tendency will be for each side tobe over defensive and both parties will lose out.When writing SLAs, it isuseful to foresee a mechanism by which the client can prioritize issues ormake urgent requests.Similarly, the SLA should allow for a degraded levelof service under exceptional conditions.Finally, there should be some wayof monitoring the level of compliance to detect problematic situations andreact accordingly, although it is probably best to look for simple indicators tostart with and to define more sophisticated metrics as experience is gained.2.7 Methodologies and frameworksMethodologies and frameworks have been grouped together, as both areused to add structure to processes.Examples of methodologies in theinformation-security area include the CRAMM [23] and the CommonMethodology for Information Technology Security Evaluation [34].Exam-ples of frameworks include Control Objectives for Information and RelatedTechnology (COBIT) [35] and ISO 17799/BS7799 [36, 37].As information-security practitioners, we come across methodologiesand frameworks in two contexts: those that we impose upon ourselves andthose that are used by others.Of the two, the latter are at least as important,if not more important, than the former.This is particularly true in the areaTLFeBOOK 2.7 Methodologies and frameworks 37of software development and acquisition, where methodologies play anincreasingly important role.Few security departments have the power toblock a promising business project once it is launched, and if the approachto information security cannot be reconciled with the approach adopted fordevelopment or acquisition, the security aspects may simply be bypassed.Before adopting any particular methodology or framework in theinformation-security area, in addition to an internal evaluation it is wellworth trying to identify other organizations that are using the approach orhave used the approach in the past.One of the key elements to look for hereis evidence that the approach has stood the test of time.Many of the exist-ing approaches place heavy demands on both IT and business staff, and thismay prove unrealistic when resources are limited.This is important, as it isprecisely during these periods that IT risk is likely to increase, and anymethodology or framework must be able to deliver under such conditions.One of the major challenges facing these more formalized approaches is therequirement to adapt quickly to changing business conditions.This require-ment covers not only the need to adapt to structural changes, but also tochanges in business strategy or a changing threat environment.Thoseapproaches that do not have this ability to adapt quickly will eventually beabandoned.One of the best ways to prepare for a stable environment in the future isto integrate the information-security requirements into the developmentmethodology, as this will encourage projects to become more activelyinvolved in the IT security aspects and present them with a unified approachto system development
[ Pobierz całość w formacie PDF ]
Tematy
Index16. Medstar II, Uzdrowicielka Jedi (Michael Reaves, Steve Perry) 20 lat przed Era Powstania Imperium
NLP Nowa Technologia Osišgania Sukcesów Andreas Steve, Faulkner Charles
informatyka programowanie uslug wcf wydanie iii juval l wy ebook
Christopher Berry Dee & Steve M Murder.com (epub)
Nizinski Stanislaw Informatyczne systemy zarzadzania eksploatacja obiektow technicznych
Reaves Michael, Perry Steve Uzdrowicielka jedi
Informatyka Europejczyka Poradnik metodyczny dla szkol ponadgimnazjalnych pormet
DÅ¡browska,Anna&inni Katalog kompetencji medialnych i informacyjnych
PhilosophySpritualActivity
Salvatore Dolina Lodowego Wichru 3 Klejnot halflinga