Tribe of Hackers Red Team. Marcus J. Carey
Чтение книги онлайн.
Читать онлайн книгу Tribe of Hackers Red Team - Marcus J. Carey страница 16
When should you introduce a formal red team into an organization’s security program?
The hard truth is that most organizations, even mature ones, don’t need a formal red team. The sole purpose of a red team is to exercise the defenders so that they will improve. The easy answer is when a program is mature enough to have the cycles to be exercised, it might be time for a red team. Red teams aren’t easy to build from scratch, and there are plenty of qualified organizations that offer their services on a temporary basis. Start there and then use them to help build, train, and augment your team when the time comes.
How do you explain the value of red teaming to a reluctant or nontechnical client or organization?
I once had the opportunity to sit next to someone on a cross-country flight who strongly believed that there was zero business value in paying for red team assessments. It was a point of view that I was unfamiliar with, so I listened to him. In the end, our views weren’t actually far from each other. The problem is that most people don’t understand what the core mission of a red team is and instead compare it to other types of testing and assessment. Red teaming doesn’t replace automated vulnerability assessments or penetration testing but rather complements it later in the defensive maturity of some organizations. Red teams aren’t for every organization, but every defender can benefit from having an adversarial mind-set. Sometimes that is hard to envision without having a trained team demonstrate it for you. Furthermore, red teams test how all of your policies and procedures work together in the actual production environment, where there are real people. For example, I have seen environments where immediate network-blocking actions were taken with minimal inspection. A few spoofed packets allowed for a large outage and a perfect social-engineering opportunity against upset, internet-deprived users. That type of logic flaw might be hard to see on paper but is much clearer thanks to the red team.
“Red teams aren’t for every organization, but every defender can benefit from having an adversarial mind-set.”
What is the least bang-for-your-buck security control that you see implemented?
It is hard to name just one. I think any device that you purchase in order to secure your environment and that adds more attack surface would be my answer. Unfortunately, that includes probably half the blinking-light appliances being peddled at the booths at most security conferences. They typically have elevated credentials stored in them and have gone through minimal testing before being advertised as the answer to all your security problems. No CISO wants to see their latest security acquisition on the report, but it happens far too often.
Have you ever recommended not doing a red team engagement?
Any honest tester should have many stories like this. While on the Army red team, we didn’t have the flexibility to offer different options most of the time because the engagements were mandated. Assessing the maturity of an environment is a critical step in the planning of an engagement, but it is often a tricky one. Years of internal and external penetration tests should occur long before a red team happens. This is further complicated by the wide misuse of the term red team throughout the industry.
What’s the most important or easiest-to-implement control that can prevent you from compromising a system or network?
Something that I have mentioned a few times in conference talks is a creative practice that legitimately caught us on an engagement. The organization used log review as a punishment of sorts for almost anything in the office. If you were late to a meeting, lost a wager on last night’s game, or failed to contribute to a swear jar, you earned log review time. The manager handed out logs from a different team for review every week, and they would produce a write-up on the most serious thing they found for the teams afterward. This had a few benefits. All teams knew that their logs would be reviewed and likely were more thorough as a result, and there was an obvious focus on security in all departments. Fresh and curious eyes were able to find anomalies that would have otherwise been lost in the noise, which led to the discovery of compromise without the use of any expensive security appliances. Finally, skills and knowledge were passed between the teams, which kept people engaged and, I believe, more satisfied in their work.
Why do you feel it is critical to stay within the rules of engagement?
The rules of engagement (ROE) are absolutely critical and need to be ironclad. Trust and professionalism are paramount to the ultimate success of a red team. If you violate the ROE, you have broken the trust the organization has put in the entire team. The time to question and adjust the ROE for everyone’s benefit is before the engagement begins. The level of access a typical team achieves during an assessment is likely greater than that of any individual admin or IT section in the organization. That trust should never be violated.
If you were ever busted on a penetration test or other engagement, how did you handle it?
I have been busted many times during assessments and could probably write an entire book on those interactions alone. One of my favorite incidents involved signing up for a conference room through social engineering, tailgating into the building, and then joining several members of the red team while we plugged into the target’s internal network. After using traditional methods of acquiring credentials, I attempted to utilize those credentials on the first interesting hostname I saw in Active Directory. We underestimated our audience, and the use of credentials over the network directly to a workstation from another workstation IP address caused an alert to prompt from their host-based security product. The warning contained my IP address, the account that I was using, and what file I was attempting to access. Unfortunately, the machine I targeted was the machine being used to project slides for a meeting that the entire IA section was attending. They jumped into action and were able to figure out where we were before I realized that I had tripped anything. We were busted, and it was all my fault. They ran into the room where we were quietly working and demanded to know who we were. Feeling responsible for the situation, I firmly told them to go get their boss so we could discuss their disturbing our work. This confused the group, but they declared that they would be right back. Afterwards, they returned to an empty conference room, and we endured a super-awkward out-brief a few days later.
What is the biggest ethical quandary you experienced while on an assigned objective?
A situation that I have encountered several times is being asked to leave out specific critical findings from a report. I imagine this is common, based on discussions with other testers. Sometimes assessments come with far greater ramifications than a tester realizes. As tests have become more normal and more organizations have publicly reported being breached, it has ideally reduced the stigma that comes with poor performance on an assessment. An experienced and properly scoped red team engagement will almost always result in a successful compromise. No one should lose their job because of it unless they are found to have violated company policies or acted unethically. The point is to train and improve the security posture of the organization and not poke people in the eye. For that reason, I am against withholding confirmed findings