Practical applications of ITSM/ITIL

Practical applications of ITSM/ITIL https://docs.microsoft.com/archive/blogs/metram/feed.xml Mark Trammell’s thoughts on operationalizing ITSM concepts, and other stuff Tue, 16 Apr 2019 06:14:03 GMT en-US hourly 1 Laying the Groundwork for a Service Management Approach (Part 1 of 6) https://docs.microsoft.com/archive/blogs/metram/laying-the-groundwork-for-a-service-management-approach-part-1-of-6 Wed, 14 Nov 2018 10:57:02 GMT https://blogs.technet.microsoft.com/metram/?p=85 mission, activities required to accomplish that mission, the roles that perform the activities, the methods used by those roles to perform the activities, and the metrics that will determine how well things are proceeding. This is by no means all that must be done, but it goes a long way. [caption id="attachment_95" align="aligncenter" width="819"]

Figure 1 - Approach to providing basic IT organizational documentation[/caption] I’ll cover mission in this entry and deal with the other steps in entries that follow.

Mission

Determining an IT team’s mission always starts with the question “so what do y’all do?” (at least that’s how I ask it). The first answer is almost always technical in nature – “we manage firewalls and other perimeter security devices”, for example – and further questions must be asked. Ultimately the goal is to write a mission statement that does at least two critical things: relates to and supports the larger mission and reflects in some manner the value the team delivers to the organization. Towards this end, the next questions are about where the team fits into the overall picture. Mission statements are needed from each of the direct line blocks on the org chart. In this way, the mission statement of the team may incorporate elements of the higher organization(s). Vision and strategy presentations from higher up the food chain may also provide inspiration. Next, scope must be determined. The team’s mission may only be scoped to certain administrative boundaries. Lastly, the value statement must be developed. My dad taught me that sometimes it is easier to understand what something is by defining what it is not, and value statements may be approached in this manner, at least for starters. What would happen if the team did not exist – if its mission were not being accomplished by anyone? This line of thinking can get you started on the road of determining value. Take our example firewall and perimeter security team. If they did not exist (of if they fail at their mission), corporate and customer data would be at great risk, potentially resulting in loss of competitive advantage, reputation, trust, and the cascade of consequences that go along with that. Their mission statement might start with something like “To protect corporate and customer data by…” and I’d be willing to bet that the need to do so could be found in the corporate values and commitments to customers, thereby linking this team’s mission to the larger picture. “To enable our company’s commitments to its customers and shareholders by protecting corporate and customer data, as well as corporate computing assets, through the operation and maintenance of a host (no pun intended) of perimeter security devices, preserving competitive advantage and contributing to a culture of trust.” Not perfect, I’m sure, but much better than that with which we started. Linking the team’s mission to the larger picture and emphasizing the value the team brings sends a message to the team members that what they do is important – it’s not just a daily grind. It also demonstrates clearly to higher-ups that this team understands the big picture and is committed to helping achieve the larger mission – rarely a bad perspective for your boss and your boss’s boss to have on you. In the next entry, we’ll look at the second step in this approach – defining the activities that must take place in order that the mission be accomplished.]]> ITIL and the DoD RMF - Part 3 of 3 – Practical Example https://docs.microsoft.com/archive/blogs/metram/itil-and-the-us-department-of-defense-risk-management-framework-part-3-of-3-practical-example Wed, 17 Oct 2018 19:40:03 GMT https://blogs.technet.microsoft.com/metram/?p=75 Part 1 of this series was an overview of the Department of Defense (DoD) Risk Management Framework (RMF). In Part 2, we looked at how process consultants may find within the RMF opportunities to positively influence the security practices of their clients. In this final entry in the series, I provide an example from my work of a client that was falling short of the requirements for a specific control, and how I approached the matter. The control in question was AC-6, least privilege. The basic premise behind this control is that accounts, especially privileged accounts, are assigned permissions/rights on systems sufficient to accomplish their duties and no more. Frequently accounts receive these permissions/rights through membership in groups which in turn have been assigned the appropriate level of access to systems. When I met with the client initially, they described to me a situation with privileged groups (and thus accounts) that was unmanageable. Hundreds and hundreds of privileged groups existed, and the organization had no way of knowing which ones were actively being used nor what levels of permissions had been assigned to the groups on which systems. Admins that had moved within the organization often retained the membership in groups from their previous role as well as receiving new privileges from their new role, resulting in cumulative privileged access of an undetermined nature. The result was great uncertainty among risk managers – a feeling of unease – and, likely, a state of system security that was somewhat less than desirable. The initial ask of this client was to find out which of the groups were needed and which were not. But even this would not address the issue of control AC-6, for there was no documentation to confirm that the groups in question possessed only the rights they needed and no more. A cursory examination of database instances showed excessive system privileges for database admins, and it was easy to believe that this sort of thing may be found elsewhere. If the task were only to take measure of which groups were needed, it would be a relatively simple (though time consuming) task to interview every technical team in the organization to determine what groups they used to grant access to the systems they managed, then compare the list of groups generated to the list in directory services, delete the delta, and see who screamed. I pitched and received permission to do something ambitious – to provide a more permanent solution. The task was great, and involved an enormous number of interviews and information gathering, review of findings, the definition of privileged roles for every team in the IT structure, implementation of new privileged groups to be assigned to those roles, a new privileged group management process (along with the corresponding forms and approval flows), and a tool to enforce policy and process discipline. This represented a significant effort but would result in a complete reversal of the situation – total faith that there existed only the privileged groups that should exist, that those groups were assigned only the access they needed and no more, and that admins would no longer accumulate permissions over time. I began the project armed with only one thing – an org chart. Email addresses and phone numbers for the folks listed on the org chart were tracked down and I began making appointments to interview team leads and their lead technicians. The goal of the initial interviews was to talk about what should be as opposed to what is. I asked first about the mission/responsibilities of the team. Then we turned to what systems the team members needed access to fulfill their responsibilities. Next the question of what tasks were performed on those systems was answered, and finally what rights/permissions were needed to accomplish those tasks. To wrap things up, we talked about whether there existed within the team different roles – different levels of access. Do new employees receive the same level of access as more senior team members? This line of questioning helped clarify the existence of different roles within the team. We named those roles, then took the data regarding systems and levels of access and identified which roles had what. The result of these interviews was a document that defined the team name and mission, the roles that existed within that team, the systems the team required access to, what tasks they needed to perform on the system, and what level of access was required to perform those tasks, organized by role. This document was reviewed by the team lead in question (and their technical representative) as well as more senior security managers. Once accepted, it was given to the directory services team to be used for the creation of privileged groups with rights/permissions tailored to the need. Privileged accounts were added to these groups and removed from all legacy groups. Functionality was tested. Once everything was settled, the legacy groups became obsolete. Upon completion of the project in total, all legacy privileged groups could be deleted. This left only the ongoing management of these groups – the need to ensure that admins who moved from team to team did not accumulate permissions. This effort seamlessly merged with another project for just-in-time-administration. A technical solution would enforce the policies and ensure process discipline. A solution founded on Microsoft Identity Manager (MIM) was engineered. Admins who needed to perform privileged actions would access a portal and check out a privileged role. The act of checking out the role added their account to the appropriate privileged group for a certain amount of time, at the end of which their privileges would be removed. Rules were put in place to ensure that the privileged users could not check out roles for which they were not approved. A mandatory field in the act of checking out a role was ticket number. This created traceability and helped ensure that privileged access was being used for a valid business reason. There were a few workflows needed – request/review/approve a privileged account, review/edit privileged group, request/review/approve permission to check out a privileged role, so forth. In the end it was a great success, and the client’s faith in the management of privileged access was dramatically improved. The requirements of the control were met, and so much more! The project required planning, communication, diplomacy, a bit of technical knowledge, and faith that the organization could achieve the way things “should be” – all required skills of a process consultant. Back to Part 2]]> ITIL and the DoD RMF - Part 2 of 3 - Security Controls https://docs.microsoft.com/archive/blogs/metram/itil-and-the-dod-rmf-part-2-of-3-security-controls Tue, 16 Oct 2018 16:30:56 GMT https://blogs.technet.microsoft.com/metram/?p=45 In Part 1, a basic overview of the United States Department of Defense (DoD) Risk Management Framework (RMF) may be found. Now we turn to the “so what” - this entry examines how process consultants may apply their knowledge and skills to assist organizations’ efforts to realize the desired outcome of the RMF. It is important to note that the RMF and the underlying security controls from the applicable NIST publications may be used by anyone, not just DoD! Indeed, NIST SP 800-37r1 states, in section 1.2, “State, local, and tribal governments, as well as private sector organizations are encouraged to consider using these guidelines, as appropriate.” The heart of the interfaces between ITIL and the RMF are the security controls. Many of them are process-oriented! Recall from Part 1 that these controls must be selected, implemented, and assessed. Process consultants may be of great use in the implementation and assessment of controls. NIST SP 800-53r1, Appendix F, contains some details about the various security controls that may be applied to systems and, most importantly to us, it provides requirements and recommendations for these controls. There are many controls that may be influenced by IT processes. Account management and privileged access are two, as well as contingency planning, and others. The one that is most obvious to me is Configuration Management, and it has an entire family of controls and requirements under it, so let’s look at that. If you were to open the NIST publication just referenced and find your way to Appendix F, you’d be able to find, somewhere in the neighborhood of page F-64, an overview of the Configuration Management family of controls. All the controls may be implemented through a Configuration Management Plan (CMP), which is a common product of process consultants. The task is to ensure that the CMP meets the requirements of this control family. When assessments find artifacts and evidence that a control is implemented correctly, and that the result is an enhanced security posture, a higher degree of assurance is attained. Enter the process consultant – we have all seen plans and process documentation wherein it is stated that things will be done a certain way, only to find that there is little to no evidence (in the form of process artifacts) that this is the case in practice. A process consultant is particularly well-suited to review a CMP and ensure that it meets the requirements for this family of controls and, if they are diligent, to provide assurance that this is so. CM-3 is of particular note – Change Management. A process consultant may evaluate the organization’s change management plan to ensure that it a) Categorizes changes and clearly defines the categories b) Provides for an information security specialist be on the change review board and that this role possesses either change decision recommendation rights or voting rights c) Requires change decisions to be documented d) Requires that change records not be closed until verification of change implementation is complete e) Provides for the archival of change decisions and implementation verifications f) Provides for audit and review of change-related activities g) Defines change review board policies and procedures All of this is merely to say that the plan meets the basic requirements of the control. The text goes on to provide even more detail as to enhancements that may be made to the control. After a review of the CMP, the act of providing assurance requires that proof be found – plans are just plans. Therefore, the consultant should a) Review change records to ensure that changes are being categorized and that the system in question is distinguishable in change records from other systems (“I’d like to see all the change records in the last year for [system].” b) Attend several change review meetings and verify that an information security specialist is in attendance and that they either make recommendations or vote. c) Review change management artifacts to ensure that change decisions have been captured. d) Review change records to see if there is evidence that they are closed only upon verification that the change is implemented. e) Ensure that the artifacts of change decisions and change records in general are archived in accordance with policy. f) Locate evidence of change implementation and ensure that it records who made the change and is tied to the change record. Also, incident records should be attributable to a change when applicable. g) Attend several change review meetings and ensure that they are conducted in accordance with policy/plan. There are scores of controls defined in the NIST publication, many of which are either directly or indirectly influenced by “traditional” IT processes such as asset management and change/configuration management, as well as the more obviously security-related ITIL processes of Security Management, IT Service Continuity Management, and Access Management. We have reviewed in this entry an example of how a process consultant may assist an organization in the implementation of the security controls required by the RMF. In Part 3 I will provide an example from my work in which a customer complained of a control not being met and how I approached the matter. Forward to Part 3 Back to Part 1]]> ITIL and the DoD RMF - Part 1 of 3 - Introduction to the RMF https://docs.microsoft.com/archive/blogs/metram/itil-and-the-dod-rmf-part-1-of-2-introduction-to-the-rmf Mon, 30 Oct 2017 21:48:07 GMT https://blogs.technet.microsoft.com/metram/?p=35 https://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/851001_2014.pdf. The RMF relies on publications from the National Institute of Standards and Technology (NIST) for the security standards it seeks to implement. The desired outcome of implementing the RMF is an IT system that is reasonably secure from cyber attacks. To achieve this end six steps are defined. Firstly, the system must be categorized – what sort of system are we dealing with? To what degree is the system exposed to cyber attack? And how damaging would be the consequences of a successful attack? After the system has been categorized, the second, and key, step occurs – selecting security controls. This is where those in charge of security for the system in question ask themselves, “from this NIST publication that defines all sorts of security controls, which do I think would help make my system more secure, and which don’t apply to this system?”. In the third step, the controls that were selected in step 2 are implemented. IT controls are a whole other topic, but for here it suffices to say that the NIST document defines the controls for us and provides some guidance as to what a “good” control looks like. The fourth step is assessing the controls that were implemented to ensure that they are performing as designed. (Think Deming – Plan, Do, Check, Act – this step is the “Check”). A “get well” plan is developed for any controls that fall short of the standard. Step five is to authorize the system – to review the security plan and controls and bless off on the system. And finally, step six is to monitor and modify the plan and controls over time as changes occur. So, as a person interested in ITIL, what does all this matter to you? On all kinds of levels is the answer, regardless of if you support DoD or not! And that is the subject of part two… For now, the summary is that the RMF seeks to provide a coordinated defense for DoD systems, and that it does so through the design and implementation of a set of security controls. By the way, the second Punic War, aside from providing the introduction, is an absolutely fascinating period of history about which to read - full of dominant personalities, romance, intrigue, and iconic military actions. It’s exciting! Forward to Part 2]]> Monitoring tools and the path of least resistance https://docs.microsoft.com/archive/blogs/metram/monitoring-tools-and-the-path-of-least-resistance Tue, 12 Sep 2017 16:25:26 GMT https://blogs.technet.microsoft.com/metram/?p=26 here – a method for placing devices into maintenance mode remotely. (Thank you, Lynne, Jeramy, and Paul!) For Operations Managers and Event Management process owners, the reduction of those (say it with me) spurious alerts is a critical success factor – we want our folks focused on actual issues, rather than chasing rabbits down holes. We may design our tools and processes in such a manner that we believe we have provided everything needed to realize our goals, but do not forget the human factor!]]> Welcome! https://docs.microsoft.com/archive/blogs/metram/welcome Thu, 03 Aug 2017 09:43:03 GMT https://blogs.technet.microsoft.com/metram/?p=25