Application Dependency Mapping: Security and Ongoing ADM

 

Well, here we are. Finally, on the last post of this series. If you have not been following along, you can find the previous posts: part one, part two, part three, part four, and part five. And, if you have been following along, I hope you have found at least something useful along the way. And for those who have left comments, I really appreciate the feedback.

So, let’s get this moving and close this series out.

 

Implementing Security Based on ADM

 

In the previous post, we briefly touched on security and I mentioned that I would save that for this post. And that is exactly what we will discuss right now. You may wonder why I saved security for this post rather than the previous one. I felt that because at least in most of my experience when dealing with ADM, the applications are the focus and security is generally not part of this, which led me to separating out the two between posts.

 

As mentioned, security is a critical component to ADM. The ideal scenario after mapping our application dependencies would be to secure communications to everything else not required for our application to function. By doing so, we can minimize the potential for any vulnerabilities which may affect our application. Now if you recall, in the last post, we also mentioned that if your ADM solution could create profiles and model the data collected, we could benefit from these when implementing our security profiles. Having the ability to model a security profile based on our application mappings, we can ensure that our application continues to function. If we were to apply a profile that affected our application, we could easily restore to a previous profile that was functional. By having these capabilities centralized we can easily manage our environment in a very holistic view. To elaborate on this, we mentioned in an earlier post that many ADM solutions require a host level agent to be installed. By using these agents, host level firewall capabilities can be managed by your ADM solution. For example, Windows firewall for Windows hosts and IPTables for Linux hosts. By doing this, we can manage security at the host level rather than at the edge.

 

Additionally, some ADM solutions may also provide reporting capabilities that show any high security vulnerabilities and patches that may be required to maintain our security posture required. This is a huge benefit to your security organization.

Not Just Once But Ongoing (ADM)

 

After you have successfully mapped out your applications dependencies and implemented a security policy if that is a requirement, ongoing ADM discoveries should be performed regularly. By doing so, we can ensure that if anything has changed, the proper measures can be taken. This will also ensure that using a new toolset to get our dependencies does not end up turning into the previous methods of tracking them in spreadsheets that become outdated relatively quickly.

 

Conclusion Of Series

 

Throughout this series, we have covered a lot of ground. The majority of what we covered was based around Application Performance Monitoring, but we also touched on Application Dependency Mapping along with security. I am hopeful that these topics have been useful, not only in being something potentially new, but also additional perspectives of possibilities that can be achieved by using a very efficient solution. I look forward to the comments around these posts to inspire additional conversations and perspectives based on other’s experiences.