I received a ton of feedback on my first post about Software Restriction Policies (SRP), thanks /r/netsec. Some of the feedback was positive, some of it critical, but all of it was important. I'll be addressing the more critical feedback today by discussing SRP in the context of the recent Adobe certification revocation news.
Just last week, Adobe announced that attackers had breached their code-signing system and have been using Adobe's valid digital certificate to sign malicious code for the past few months. Of course, Adobe has since taken actions to fix the problem; however, this blog isn't about the resolution of security incidents. Rather, this blog is about posturing your organization to detect and deflect this and other APT/crime-ware/nuisance attacks.
Whitelisting and the Adobe Problem
Application control and white-listing solutions are designed around the concept of "digital trust" for the sake of scalability and management. I realize that not all organizations that implement whitelisting use this trust feature, but typically the ones large enough to be a target do. Anyway, "Digital trust" means that when a piece of software is signed with a valid digital certificate, our computer can "trust" that the software is from the source associated with the digital certificate (i.e. Adobe). When our application whitelisting software (Bit 9, Bouncer, or other) see Adobe's certificate has signed a piece of code, that code is allowed to execute.
The problem is glaring. Typical application whitelisting software would have allowed the malicious code signed by the Adobe certificate. Now, of course, there are reactive configuration changes that can be made to fix this, but we want to be proactive.
SRP and the Adobe Problem
SRP relies on operator context and protected directories. Certificate trust is an option with SRP, but hardly a necessity. With SRP and an access control list (ACL), you can separate your machine in to two logical areas:
.png)
If you are in the context of a regular user (as opposed to administrative context), you cannot execute anything from user locations. Further, from this context, you cannot write to protected directories. In other words, users can only execute files in directories they cannot write to, never files that they've downloaded or created.
As for administrators, they can execute from pretty much anywhere on a machine. However, I recommend blocking key areas where malicious code typically lives (Internet Temporary Files). Further, SRP can be applied to just about any file extension from .pif to .bat to .dll. It's a good idea to baseline your organization's critical applications and adapt a SRP policy around them. Also, It's hard to compete with the free price tag.
Just last week, Adobe announced that attackers had breached their code-signing system and have been using Adobe's valid digital certificate to sign malicious code for the past few months. Of course, Adobe has since taken actions to fix the problem; however, this blog isn't about the resolution of security incidents. Rather, this blog is about posturing your organization to detect and deflect this and other APT/crime-ware/nuisance attacks.
Whitelisting and the Adobe Problem
Application control and white-listing solutions are designed around the concept of "digital trust" for the sake of scalability and management. I realize that not all organizations that implement whitelisting use this trust feature, but typically the ones large enough to be a target do. Anyway, "Digital trust" means that when a piece of software is signed with a valid digital certificate, our computer can "trust" that the software is from the source associated with the digital certificate (i.e. Adobe). When our application whitelisting software (Bit 9, Bouncer, or other) see Adobe's certificate has signed a piece of code, that code is allowed to execute.
The problem is glaring. Typical application whitelisting software would have allowed the malicious code signed by the Adobe certificate. Now, of course, there are reactive configuration changes that can be made to fix this, but we want to be proactive.
SRP and the Adobe Problem
SRP relies on operator context and protected directories. Certificate trust is an option with SRP, but hardly a necessity. With SRP and an access control list (ACL), you can separate your machine in to two logical areas:
.png)
If you are in the context of a regular user (as opposed to administrative context), you cannot execute anything from user locations. Further, from this context, you cannot write to protected directories. In other words, users can only execute files in directories they cannot write to, never files that they've downloaded or created.
As for administrators, they can execute from pretty much anywhere on a machine. However, I recommend blocking key areas where malicious code typically lives (Internet Temporary Files). Further, SRP can be applied to just about any file extension from .pif to .bat to .dll. It's a good idea to baseline your organization's critical applications and adapt a SRP policy around them. Also, It's hard to compete with the free price tag.
good
ReplyDeleteSPR is a very interesting proposal to secure the machines form viruses and malware. It is dangerous that even SW of big and well known companies as Adobe can spread malicious code.
ReplyDelete