One of my favorite parts of penetration testing is and always has been social engineering. I love it. In fact, I love it so much; I developed a real passion for it. My passion led well beyond the traditional social engineering and evolved into the study and practice of more sophisticated techniques associated with socio-psycho manipulation. It is a gift of sorts and who am I to question a gift? When speaking with prospective or current clients with respect to security assessments I have often implored them to include both physical security analysis and social engineering. This habit was formed upon entry into the world of professional security consulting where I sharpened these skills under the tutelage of many senior to me in both age and experience. Almost all of my earliest mentors in this space were or had been active in the United States DoD or like intelligence services, most of whom shared a common pedigree not unlike my own hailing from the world of information security and intelligence. These environments taught us to remain vigilant and open to idea that the unexpected should be expected therefore our ability to address anomalous events must remain categorically strong.
Over the years, within many engagements, activities of this nature were written into SoWs (Statements of Work for the lay person), and acted upon with full approval of parties both able to authorize such activity within and against their organizations and their legal representation (a detail I cannot stress enough that should not be overlooked). We would engage reconnaissance carefully leveraging skills we had cultivated in our former lives and applying them to the commercial world. We would engage in deep open source intelligence gathering and analysis in order to supplement our knowledge base regarding our target(s). We would become familiar with the physical environment in which our targets could and would likely be found. These locations would range from their places of business, to local restaurants and pubs, to local shopping districts to other geographic locales that we knew to be frequented by parties belonging to the organization, our target, in question. All the while we would be looking for ingress and egress points in addition to ideal areas for initial contact and exploitation. We would additionally identified areas in which useful information may or not be discarded by our targets that truly believed that no one would be interested (ah how I loved dumpster diving in my youth!). Finally, upon having enough information we would begin our careful insertion and infiltration. There is an art to doing this as much as there is a science and at times, the art becomes (or at least in my experience became), much more valuable.
These exercises almost always proved fruitful, as they would typically be multi-faceted involving multiple small teams each of which was cognizant of the others activities but all tasked with different missions during these exercises within the greater assessment. Some teams focused more upon the physical compromise of the environment, the acquisition of credentials and knowledge which could be socially engineered or stolen and thus counterfeited to serve our purposes in pushing deeper into the environment escalating our mission per our SoW and charter. Others would work on compromising individuals, seeking to gain their trust and subsequently their knowledge and any information considered noteworthy. Others still work on electronic and social engineering utilizing e-mail, web and telephonic techniques all designed to gain the trust of our targets or members of our target organizations in the hopes of escalating our privileges and advancing our efforts. This was good work. It was important work. And it was work that not all are capable of nor designed for. To the layperson reading this post I imagine it sounds outrageous if not frightening that work of this nature goes on and is conducted by security professionals in an effort to test and assess the security posture of a client and to a degree I can understand that attitude. However, this work is terribly important and often demonstrates weaknesses not previously accounted for within enterprise environments (public or private), during traditional security assessments and audits.
At this point you may be wondering whether or not there is merit in engaging a qualified team to do provide this type of service in addition to traditional services brought to the table as part of a security assessment. My personal perspective is that if you have overt responsible for the risk posture of an organization and understand that security or the state of being secure is contingent upon the three legs of the security stool (people, process and technology) being dutifully tested and exercised you most assuredly should do so. Failure to do so can expose you and your organization to a world of risk, which complying mindlessly with a three lettered data security standard or a mutagenic health-privacy act cannot hope to save you from. So what are we to do? First, if you haven’t already done so, conduct a meticulous review and analysis of your organizational information and physical security policies. If you don’t have any now is the time to remedy this deficiency. Should you (as I imagine most do, but will refrain from assuming), have these policies on hand review while employing a healthy dose of third party ego; remove yourself from the immediate, intimate involvement with them as they relate to your job and evaluate them as though you were brought in to do so as a third party. Do they look mature? Are they clearly articulated and well defined? Are they comprehensive? Do they address the natural bridges that occur between physical and logical security? Provided you have the resources, engage them to conduct preliminary assessments (provided they are qualified to do so), and if they are found to be lacking in the ability, do not hesitate to contact professionals with the appropriate pedigree, background and reputation to speak to about scoping a statement of work on your behalf. Remember that not every attack of a truly serious nature takes place across a wire and that many begin and end with a simple telephone call, a conversation around a smoking area or via a new hire.
When Antivirus becomes the Virus
Full Disclosure – I am a former McAfee employee, and currently draw a paycheck from a McAfee partner. The following are clearly my own thoughts and do not represent McAfee, my current/former employer(s) or anyone else.
Having been in the IT security industry for at least a decade, I have come to two key realizations:
1.) The IT security industry, as it relates to vendors selling products is largely based on FUD (fear, uncertainty, doubt), and
2.) Antivirus in almost no significant way equals comprehensive security
As many across the interwebs have already brought to light, McAfee had a very public snafu with one of their DAT updates (DAT 5958). Here is a mildly humorous link from Engadget’s site. To be clear, the point of this post is not to say the antivirus market poor or is dead, that McAfee has substandard products or solutions (usually the contrary), but that mistakes like this hurt not just one vendor or end customer, but the entire industry at large suffers.
That last part is an important point, especially in the case of endpoint security. Mistakes happen. QA processes are not perfect, vendors are trying to cut costs at every turn to increase profitability, so these things happen. In this specific case, if you were running VirusScan Enterprise with default settings, you will be a bit better than those who enabled “scan process by enable” or ran an on-demand scan with the 5958 DAT and scanned svchost.exe as the SVP of McAfee Support mentions in his blog post.
I see this with a lot of security practitioners where they turn on non-default options and get burned. Again, not picking on McAfee, but they also had a recent issue in their Patch 3 release of VirusScan Enterprise 8.7i where you enable “Prevent Windows Process Spoofing” (also an option that is disabled by default). This does not affect you if you don’t start turning on options you don’t fully understand. So, if you are responsible for endpoint security, a few simple tips:
1.) Have an IT test environment in place. Like Noah’s Ark, have representative systems (hardware, OS levels and apps installed) to test before you deploy. Many large enterprises wait 12-24 hours before rolling out DATs, and those who did were largely unaffected by this issue. Vendors like to throw around FUD here and push people to deploy reactive DAT coverage, and in few instances does security supercede system availability.
2.) Stick with the default options unless you are ready to accept the consequences – if you left the default options in place, neither of these two recent McAfee issues would have affected you. Quit turning knobs when you don’t fully understand what they do. A lot of us in IT assume instead of “trust but verify”.
3.) On-Demand scans are of minimal help on end workstations. AV scanning, especially on a scheduled basis is reactive. You already have malcode. Use realtime protection/on-access scanning, whatever. Save the scheduled reactive scanning for your file servers, SharePoint, and other file and data repositories.
4.) Antivirus is not total security, it is only one countermeasure. And, most importantly it is a reactive countermeasure at that. Regardless of what spin vendors put on it (heuristics, sandboxing, lookups in the cloud, etc.) by its very nature it is a reactive countermeasure. Implement more/better countermeasures, which leads me to …
5.) Complement endpoint security with more than just desktop and network firewalls. If you don’t use Host-based Intrusion Prevention on your laptops and critical systems, you probably should. Big difference in detecting malicious code or signature viruses versus stopping malicious traffic, and there is way more to it than blocking a port or protocol.
The point of this is not to unleash a hit piece on a specific vendor or technology, but to make sure practitioners frame the security tools and countermeasures in the appropriate context. AV won’t save you from malicious traffic for the most part, or from a targeted attack. Just like network security is not the answer to all of your security issues. The answer is an honest assessment of your countermeasures and their configurations, and if that maps to an acceptable level of protection versus risk. Sounds so simple, yet the devil’s in the details.
Threat Modeling
Threat Modeling
For most of us, the concept of ‘Threat Modeling’ takes on different meanings based upon our experiences, areas of expertise, areas of interest and comprehension of what constitutes and is defined as a ‘threat’ by industry and by ourselves. For man, ‘Threat Modeling’ is the realm of the developer. It is an area of expertise, which specifically addresses security, concerns of interest to them while for others, ‘Threat Modeling’ is used during assessment work. It is during these assessments, most of which are specific to code analysis and review, which we see many use these techniques to formulate and define more robust ‘Threat Models’ vis a vis the definition of potential attacks and exploits. Regardless of the definition you subscribe to, we can assume that ‘Threat Modeling’ accounts for much, but does it account for everything we need it to?
Threat Modeling Attributes
It’s important to note that ‘Threat Modeling’ has undergone much change over the last decade. It has experienced evolution and likely will need to going forward as both the application of the act of ‘Threat Modeling’ as well as the philosophy behind it, continues to evolve and grow. This is really rather non-negotiable when one looks at the current state of technological advancement we are in today and where we dare to take ourselves. As a result, we can assume the following of ‘Threat Modeling’:
- There are traditionally three commonly held views of ‘Threat Models’
- Attacker Centric
- Application / Software Centric
- Asset Centric
- ‘Threat modeling’ can be related to any asset deemed to posses worth and be considered of value to an individual or organization
- Personnel
- Facilities
- Applications
- Systems
- Networks
Identification and declaration of exactly what defines an asset is crucial to the process of ‘Threat Modeling’, failure to perform due diligence here will be noted and likely lamented in post mortem investigations.
- It is the desire of the owner or the party(s) tasked with stewardship of the asset in question to protect and ensure the safety of the asset (and any associated / related assets)
If there is any doubt as to whether or not it is the intent of those tasked with responsibility and stewardship for all defined assets, ‘Threat Modeling’, though still important should not be the first order of business!
- All assets have points of vulnerability
- All points of vulnerability can be exploited if left unaddressed or if addressed in appropriately
- Vulnerabilities can be exploited via internal or external means
We live in an imperfect world and as a result, all things; even the most cleverly engineered – organic or inorganic, have flaws. Assuming otherwise is a failure of logic and will almost always lead to a fall. Accepting that all things have vulnerabilities and are susceptible to exploitation knowing that these vulnerabilities can be remediated and the risk mitigated is of paramount importance to the success or failure of ‘Threat Modeling’ exercises or any associated activities.
- Useful in developing in countermeasures
This is of course quite elementary and obvious yet it is something that needs re-enforcement for several reasons not the least of which is that many despite this obvious benefit or by product depending on your point of view, still will not endeavor to engage in formalized ‘Threat Modeling’.
- Can be focused on defense or offense
This, I believe is self-explanatory as one might, again taking into consideration their working definition of ‘Threat Modeling’ into account either look at is as a defensive activity as we discussed earlier or as a mechanism useful, if not paramount, in offensively compromising an asset.
Where to Begin With Threat Modeling?
At a very base level, one needs to ask oneself some key questions prior to engaging in the activity of ‘Threat Modeling’ in order to avoid any oversights or mistakes. These questions are rather elementary yet their value cannot be emphasized enough. They provide the ‘looking glass’ if you will, which is necessary in order to successful model threats and gain the most value from the activity. Some of common questions which one should endeavor to ask and answer may look like (but by no means need reflect verbatim):
- What are the assets you need to protect?
- Where do they reside?
- Who are your customers? User community?
- Who are your adversaries?
- What are your strengths?
- What are your weaknesses?
- What can be done to minimize the attack surface and mitigate risk?
- How often should you engage in this process?
In going through this exercise, trivial though it may seem, a great deal of valuable information and data points may be collected and assessed for their use and application during ‘Threat Modeling’ activities.
Models At Our Disposal
There are many models currently in use today. Some are more focused or directed towards developers while others focus more on the needs of assessors and auditors. Regardless there is no one single way to go about conducting ‘Threat Modeling’. Below are a few wonderful examples of current ‘Threat Modeling’ methodologies & resources:
A View To A Kill: Executing a Threat Model and Processing The Results
- Picking Your Poison: Deciding on Threat Model
- Executing a Threat Model after exhaustive data gathering & analysis of said data
- Post Mortem: Examining the Remains
- Lessons Learned: Planning for the Future
- It’s a Cycle: Wash, Rinse, Repeat
Conclusion:
The value presented by the activity associated with ‘Threat Modeling’ is difficult to argue against. ‘Threat Modeling’ provides a vast amount of data and can aid both individuals and organizations (in quantitative and qualitative terms), in a multitude of ways not the least of which is providing clarity into the vulnerability of an asset or potential for exploitation of an asset. Failure to undertake these activities is akin to dereliction of duty for developers and assessors alike as those with nefarious intent not fail to exhaust every measure at their disposal to accomplish their mission.
