Chris KatzSecurity and Risk. Two words that strike fear in the hearts of the unprepared. No matter what your role is within the organization, these words can keep business leaders awake well into the wee hours. Recently, we worked with a large telecommunications company that was faced with solving significant security issues putting the organization at risk.
Generally, this telecom was unable to report on risks within their Microsoft Dynamics AX 2012 application, which in turn generated a number of other issues. Specifically, those compounded issues included:
- Recent audit findings resulted in audit exceptions, generating significant manual effort to gather sufficient look-back documentation
- Inconsistent protocols in provisioning access to AX 2012
- Periodic user access reviews were difficult to perform, due to limitations of available access reporting and analysis capabilities
- Protocols regarding the usage of the System Administrator account and who should have access were not always defined
- Custom roles had been created, but security architecture was disorganized and was hard to interpret what existed within each role
With this background, our project objectives were to: 1) redefine the Segregation of Duty (SoD) and sensitive access ruleset; 2) establish flexible and secure role architecture; and 3) eliminate unnecessary access and document mitigated controls.
Our initial timeline was 11 weeks. With such a tight timeline, work began on three parallel paths including redesign, Fastpath implementation and establishing future state governance. It was critical to customize the ruleset for this client, as it would be the key to exception-based risk management.
When it came to defining roles, we considered job-based and task-based security roles. The client opted for the former, and we mutually implemented a “building blocks” approach to defining those roles. We began by stacking the task-based roles together. Next, we put them into a job-based role. It was critical to maintain a standard approach for assigning security. By ensuring that privileges were assigned to duties, duties were assigned to task-based roles and task-based roles were assigned to job-based roles, a scalable security structure emerged that the client could use as its needs grew and evolved.
The role architecture is four-tiered, ensuring users are granted access in a structured way to minimize risk potential and excessive access. Tier 1, or general access included birthright roles such as time entry or HR information on each employee. Tier 2, display access, carried minimum sensitivity, while Tier 3, update activity access, had medium to high sensitivity. At the top of the architecture is Tier 4, critical sensitivity, where IT and sensitive functions such as setups, user assignments and role modifications are housed.
As with most security projects, there were inherent challenges, perhaps the biggest of which was coordinating the various stakeholders across the client organization. This was not “just” an IT project or accounting project – the client was keen to work across business units. The client’s audit teams lacked experience in the AX security model, Fastpath functionality and how to best audit security. Those challenges were complicated by the complexity of the AX security model and the impacts even minor modifications can have on user functionality.
But with every challenge comes a new opportunity to develop a creative solution. In this case, we learned that having the organization’s senior leadership clearly communicate the importance of the project helped stakeholders prioritize appropriately. The client also ensured that both internal and external audit teams were well informed of the project objectives, direction and approach. Throughout, we gathered feedback and implemented suggestions, which further contributed to the overall buy-in of the organization to the project objectives.
Finally, the project timeline eventually extended to 22 weeks, double the time initially estimated. Why? It was clear early on that a “Big Bang” approach was not appropriate here. Testing was detailed, thorough and required a number of iterations. We extended the testing schedule and established a rigid process for ensuring all roles were tested and vetted prior to going live.
As with most projects, this work taught us important lessons we will carry into future security projects and which, in hindsight, are valuable objectives for any major undertaking:
- Executive leadership is critical – getting buy-in from the top smooths the road ahead
- Establish/update governance processes
- Don’t underestimate user acceptance testing
- Know what is mission critical – don’t get sidetracked by non-essential one-offs
Don’t lose sleep at night. Have a solid plan and use your “building blocks” to win.
Warren Fish
Jon Medina
Nishi Prasad
Julia Artzi
