Tag Archives: Intel

When and How to Hire a Threat Intelligence Analyst

WHEN…

Threat Intelligence has become the latest marketing buzzword, often abused and misused in an effort to impress a customer base. So, when do you need threat intelligence and when is the right time to hire someone to “provide customers” with threat intelligence? Well, you should never hire someone specifically to provide customers with threat intelligence, unless that is the product you are specifically in business to produce. You can read more about this in the blog “Three Myths about Threat Intelligence.

Typically, you would be ready to hire a threat intelligence analyst once you’ve established mature security practices for your organization. This is not to say that a Threat Intelligence team cannot be set up and designed to grow as the company grows, however, it is typically a strategic investment where the Threat Intelligence team’s first role is to serve internally, supporting decision makers, it also serves to strengthen the security posture and proactively detect, deter, and destroy/avoid threats. While start-ups would benefit from understanding threats to their products, people, facilities, and customer data, they do not typically plan for the capital investment to support threat intelligence efforts. Additionally, Threat Intelligence teams do not normally generate products for revenue; rather, they serve to inform decision makers about potential threats on the horizon, protect the organization from internal and external threats to people, property, and assets, and in rare instances provide competitive advantage. In short, you are probably ready to hire once you are ready to make a strategic investment and take a proactive approach to security and threat detection, deterrence, and avoidance.

Below is a brief checklist of things an organization should achieve before being ready to hire a threat intelligence analyst.

  • Mature security processes and culture in place
  • Obtained CEO, CFO, CIO support and buy-in from Legal, Marketing, Physical & Information Security
  • Structured the Director of Threat Intelligence and his/her team to report directly to a C-level officer, optimally the Chief Security Officer
  • Completed a threat intelligence program charter and program outline
  • Defined the immediate intelligence requirements
  • Defined communications plans for intelligence dissemination internally and externally

ONE PERSON CANNOT EFFECTIVELY SERVE TWO MASTERS

Once you’ve completed the tasks above, you should be ready for the next phase – hiring in preparation for collection and analysis. You should not have started any intelligence collection aside of what may already be generating inside individual departments: network logs, market reports, incident reports, etc.

Your first hire should be a managerial role that will oversee the persons performing collection and analysis. While it will be immensely beneficial to hire someone who has experience within the intelligence community, it is not a requirement. Conversely, someone skilled in managing “geeks” or “nerds” is a minimal requirement.  

When under tight budget constraints, companies often try to cut corners and hire someone skilled in both collection and analysis, having them perform both full-time roles, i.e. two masters. This does not scale and is not sustainable. While it may work initially, you will quickly learn that time spent serving the first master Collection & Processing (collecting intelligence, developing tools, and tuning collectors) is time that cannot be spent serving the second master Analysis and Reporting (doing robust analysis of the threat data that has been collected). The individual cannot serve two masters (do both jobs) indefinitely.

At a minimum, you should plan on having a developer to focus on developing, integrating, and tuning intelligence collection tools. This person will also work with analysts to develop tools and processes for converting the collected data into formats the analysts can use, a phase known as intelligence processing. The team/person responsible for developing the tools will have an intimate relationship with the analysts consuming the data/information that has been collected and processed. Whether you hire the threat intelligence analyst or the developer first is not important, however, them being able to effectively communicate with each other and having a solid understanding of what the other one does is important.

HOW…

Know the traits you need in a threat intelligence analyst and realize a great analyst may not have “analyst” in their previous job titles. More importantly, a person’s mindset and character often make the difference between a good and great analyst, not their years on the job. A good threat intelligence analyst, while unique in their own way, shares many characteristics with analysts from other disciplines. So, what traits and skills should they possess?

First, they should be able to WRITE CONCISELY. This is a skill commonly found in journalists, historians, and researchers. Look for someone who has experience in public affairs, school newspapers, blogging.  If an analyst cannot communicate the importance of the threat in a short, concise manner, decision makers will likely not find value in their reporting. If an analyst cannot show value, leaders can (and often quickly) form the opinion threat intelligence is a useless money pit.

Second, a good analyst is a professional tin-foil hat model, never trusting an analysis without knowing what methods and data were used to generate a report and how it was collected. They are skeptical, ask lots of questions, and think outside the box.

Third, they should be humble, admit their mistakes, and learn from them. Sometimes an analysis can go horribly wrong, and when it does, it makes front page news. This doesn’t necessarily mean the analyst is a bad analyst, at least as long as they learn from it. It may be they were pressured to provide a report based on insufficient or corrupted source data and didn’t push back for more time to consider other explanations of the data, or maybe they were unaware of their own bias. Whatever the cause, a good analyst can identify where the analysis went wrong and learn from the error(s).

Fourth, a threat intelligence analyst needs to have comprehensive knowledge on the subject or be able to quickly ramp up. For example, an analyst with one year of security experience who also has in-depth knowledge of religious and cultural practices from a geographic region where your biggest threats reside can be just as valuable to a threat intelligence team as someone with ten years of security experience and no relevant geographical or religious knowledge or experience.

Fifth, they know the tools and data resources available for collecting intelligence. Often, the hardest part of collecting intelligence is knowing where it is, how to get it, and the ability to find new sources.

Sixth, a good analyst has refined technical skills with respect to understanding how data is/was collected and processed, as well as knowing when data is missing and being able to explain why it is missing. This helps them know when to question the collection results and how to work with the collection team to tune the methods, techniques and processes. Additionally, they should have advanced skills when it comes to collating data points for analysis in order to identify relationships and trends.

Finally, they should have a solid understanding of and experience in developing and testing hypotheses, to include communicating the methods used, assumptions made, data that is missing, and potential biases.

GOOD TO GREAT

A great analyst is one who is willing to review someone else’s hypothesis, theory, model, etc. Then, if the data supports it, admit that while his/her assessment may differ, that they are both viable. Many times, the best analysis can be a hybrid of theories from different individuals who had very opposite starting points, combining the best of each analysis to create the final product. Additionally, when a theory or hypothesis is disproven, or the data doesn’t support it, they need to have a “no-quit” mentality in continuing to chip away at it until they have a theory that is supported by the data.

In addition to willfully accepting other’s evaluations and assessments, a great analyst is also cognizant of his/her own bias. For example, a 50-year old male analyst from Ohio who grew up in a Christian home and never traveled more than 250 miles from home is probably going to have a very different set of biases that influence his/her analyses than a 50-year old male analyst from Mississippi who spent 20 years in the military and is an atheist. The ability to admit one’s own bias is something that is often found in someone that is able to have academic discussions, being able to say, “I understand your argument, I just don’t agree with it.” Being self-aware and able to admit one’s own bias is a trait often overlooked in the interview process.

IT’S ALL ABOUT THE BIAS…

So, which of all of these things discussed above is the most critical characteristic of a threat intelligence analyst? Only the last one, the ability to admit one’s own bias. You definitely hope to find a threat intelligence analyst who embodies all of the listed traits that constitute a good and great analyst, however, at the end of it all, the ability to admit one’s own bias turns out to be the foundation upon which most of these other traits sits.

Finally, the most important, they are willing to admit when they are wrong, and even more importantly, when someone else is correct.

Beyond Whack-a-Mole “Intel”

In recent days I had some conversations with folks regarding the common INFOSEC comprehension of threat intelligence and what it really is, and we all come back a marketing buzz phrase “actionable intel”. My concern is that the definition of “action” seems to be getting diluted these days and at worst it has been morphed into “write a signature to prevent X” or create some hot new technology that uses artificial intelligence to anticipate ABC and block the attack. Also, everyone wants to be first to blog about the latest threat that hit the landscape. Researches spend hours trudging through dashboards, PCAPs, log files and retro hunting with yara rules looking for that needle in a mountain of needles that is sitting inside of their grandmothers sewing bench, and hope they don’t prick themselves wasting time with “unrelated” data or false positives. We’re inundated and consumed with the tactical execution. Why? Money, and possibly a case of nearsightedness.

Businesses are consumed by needing to show immediate value (nearsighted), and value is usually measured in the number of bad things blocked. Thus the tactical war against malicious actors saturates every aspect of our information security programs, our hiring for INFOSEC roles, the reports we produce, the metrics we pull our hair out trying to develop, and most of all BUDGET – where we spend our money. We are at constant war, just ask any incident response, forensics, malware reverse engineer, threat researcher, or SOC analyst – it is an all out 24/7 war against bad guys, and one thing you need to win a war besides soldiers, beans and bullets? Strategy.

Strategic operations are nothing new to any military organizations. Nor is strategy new to any successful CEO trying to position his company to gain a competitive advantage over a market share, but strategic planning and execution to an INFOSEC threat intelligence team seems to be as foreign as a fully nude woman standing in the flesh in front of a virgin. The concepts of profiling, understanding, and anticipating your enemy so that you can not only win battles but win the war, are something I find few people grasp. Make no mistake, I am not saying that the tactical activities mentioned above are without merit, they are 100% critical and vital to protecting assets both tangible and intangible, and even lives. What I am saying is that, organizations that have reached a maturity level where they are effective with near-surgical precision in squashing malware and phishing attacks, should be looking to take things to the next level.

I tweeted recently something to the effect that the words “new malware” literally have a Pavlov’s effect on threat researchers. Everyone gets excited about the shiny new malware, we all want to rip it apart, see how it works, hopefully find flaws in it, & blog about and HOPEFULLY to share indicators of compromise (IOCs) with the whole world to make the Internet a safer place. (Side rant – if you blog about threats and don’t share IOC’s and actionable intel, IMHO you are a douche nozzle being used for an enema) Back to the topic at hand…..We want to tell everyone how the malware did it’s backflip, blindfolded, across hot coals and broken glass, shit a peanut that turned into a malware tree, that bloomed ransomware buds whose pollen poisoned the threat landscape and that’s how we got money to grow on trees. Okay, not exactly, but close enough. But then what? Then we all go back to looking for the next shiny piece of malware, cuz we can never have too many in our collection right? Well, this all falls into tactical operations, a very instrumental element to protecting and defending our orgs and current customers, not to mention attracting new customers. The race is to be the one that finds it first, blogs first, and makes current and potential customers feel safer – basically whack the mole the fastest and most accurately. Heaven forbid if another organization blogs about some new major threat and you didn’t, your org is destined to get a tsunami of “are we protected” inquiries. And of course, that’s what the business is worried about – happy customers who feel safe because that’s what pays the bills. So I ask again, but then what?

In all of this, after the hours spent finding it, ripping it apart, and figuring out which IP or domain it came from so you can write a signature, blacklist and block it, what have you learned about your enemy? Better yet, what have you converted from an observation into codified knowledge that can be used later – that is not an IOC? What do you know about their objectives, short and long term? What do you know about their resource needs, infrastructure, motivations (are they political or financial)? Trying to teach strategic threat research in one blog post is insane, so I’ll try to give an example via an imaginary conversation.

*****************************************************************
Do you know or understand why *THAT* malware was used against *THAT* organization? NO

What about that domain, have you run down the registrant to see what other domains he/she owns and if there’s any other malware associated with them? YES

Oh really! Well do you know if it’s the same kind of malware? It’s not

It’s not? Well bad actors are kind of like serial killers they usually have a modus operandi (method of operation) aka M.O., a habit, that they rarely deviate from, so why did you actor change his M.O.? I don’t know

OK, go figure out if something caused your actor to change his M.O or if this indicates multiple actors sharing the same registration information.

Is it on a dedicated/shared IP? SHARED, on an ISP that only owns 200 IPs and only hosts 100 domains, and they’re behind bulletproof hosting

Do you have enough information based on victims to build a potential target profile so we can figure out where/who they might attack next? NO

What vertical was that attack against? Transportation

What org? a trucking company

What geographic region? Timbuktu

Are there any key political figures headed to that region? sporting events coming up? tourist or entertainment events planned in the near future? Yes

Really, hmm what other resources are needed to support (X from previous question)? Catering? Power? Decorating? Air Travel? Yes
*****************************************************************

Now the scenario above is completely made up, and there is an entire line of questions that could follow. In fact, changing the answer to any one question can change the next round of questions that would follow. Nonetheless I think you get my point. And if you really do get my point, then you’ll understand why a massive “threat intelligence feed” from a company is practically useless. You’re better off just ingesting a black/whitelist from some trusted asset with an understanding that you may have false positives, but you’d rather be secure and inconvenienced. It is time the INFOSEC community take threat intelligence to a new level and start looking past the shiny new malware and actually start trying to understand attackers.

It kind of reminds me of the sci-fi movie I watched this weekend (I won’t name it because I don’t want to get sued). Basically our planet had been attacked in the past and we defeated the enemy. Then the humans studied the technology left behind from the aliens. They used it to advance the human race and unite the world. But then years later, another alien shows up, without hesitation we blasted it out of the sky, then a bigger alien shows up and threatens the planet again. However, a group of scientists takes the time to study and understand the first alien that showed up those years later. They come to find out the motivation behind that alien, learn from their observations and if they apply the knowledge correctly they can then ultimately defeat the massive alien force that now threatens them.

The key here, is that they took time to study – let me type that out a little more slowly “T H E Y T O O K **T I M E**” to “S T U D Y” – of course it was after they whacked the mole, but they did do the deeper investigation. This is where we all need to be headed. After we’ve honed our skills at quickly finding and annihilating the immediate threat, let’s start adding a new function to our INFOSEC portfolios: teams to do strategic analysis, enemy profiling, and developing threat intelligence that allows us to take proactive measures to prevent attacks or at the very least identify behaviors that indicate a larger (measured by impact not volume) threat on the battlefield.

THE END 🙂

BTW, Business people – please pick your faces up off the floor, I know, I just said we need to invest time and money into something that has long-term payouts and not immediate ones. Let me know if you need me to pay your co-pay for your hospital visit.

As always, thanks for reading and supporting.

Stop Having Sex for the First Time – part 2

In the first part of this article, I gave some various examples of how InfoSec teams are structured to fail or at the very least function very inefficiently. Next we’ll talk about how to achieve a more effective *INTEL* team – and how it will enable the development of intelligence in the organization.

FIRST: Specialization Without Division –
So, here’s where experience in the bedroom really pans out in this InfoSecsy relationship. You want to get lots of smart people who each excel at one thing but know a little bit about a lot of related things.

Both InfoSec & Intel teams will benefit from this structure, the caveat is that you must also have people with the right personality (nobody likes selfishness in the sheets). In addition to the right mix of talent, you need people that respect each other’s abilities, aren’t afraid to ask for help and will be willing and even eager to share what they find. You don’t need a bunch of multipurpose rock stars, rather you want people who excel at things such as malware reverse engineering, pcap analysis, social engineering, development, data analysis, and even specific application software etc. You also want them to have foundation knowledge in other security realms.

The second part to this is that they are ONE TEAM, they are not divided into divisions with Directors and VPs over specific areas rather they are outside hires or even the internal elite from the network security team, the security operations center, the devops team etc. They will likely have liasion relationships with these functional areas and access to the data from them as well.

In some cases it may make sense to have multiple teams located together across the country, in some cases the company size may support having them co-locate in one physical space, nonetheless the bottom line is that they are all ONE Team. They are your version of a special forces troop, everyone has a job yet they all help each other and are willing to learn what they can about another area to be as effective and helpful as possible when needed.
SECOND: In Failure and Success, in Sickness and in Health ’til Termination Do We Part

This is an InfoSecsy partnership whether you like it or not. If an attack on your organization succeeds or fails, you share the responsibility. If you build something, and it doesn’t work, you share the failure and when it does, you share the success. If you have an idea and it leads nowhere, you mark it off as something tried and eliminated. If you have an idea, try it, if it fails tell everyone WHY/HOW it failed so they don’t waste resources trying the same thing, then move on. If you try something and it succeeds, share so everyone knows WHY/HOW it worked and they can repeat, enhance, and also succeed. [Ask @Ben0xA for his preso on FIAL – it’s awesome]
THIRD: share, Share, SHare, SHAre, SHARe, SHARE, SHARE!!!!!

Sharing InfoSecsy knowledge, skills, experience and ideas is only going to enhance your Intel team and company’s security posture. For example, the other day I had someone tell me that an Exchange team was unable to help us identify who clicked on a link while accessing OWA on a machine because everyone shared a generic login on the shared workstation. Having similar experience in a related area, I was able to offer a suggestion to the Exchange Team and the SOC Analyst that allowed the proper syslogs to be identified in their repository and the Exchange Team to liason with the Windows IIS team to pull the data that was later analyzed. Neither of these areas was my responsibility or expertise, but due to their willingness to share the problem and brainstorm, solutions emerged.
Another example, When we had a host that was unable to be found, I got the NOC, SOC and Help Desk all talking and we collectively came up with a non-traditional way to protect the network and find the asset. While I didn’t know the topology I was able to ask questions that spawned conversations that resulted in solutions.

Sometimes the person with the LEAST knowledge in a subject area can ask the simplest question that will light a much needed fire when because of how they processed the information. The bottom line is – get your people together regularly to discuss what has/is happened, known, and is yet to be figured out, and collectively, ideas and solutions will emerge.
FINALLY: Recycle & Re-Use

For this final note, I’ll use a hypothetical incident as an example. A Sales Engineer (SE) gets an email from an individual purportedly representing one if his clients. The individual is asking for assistance in collecting network and netflow data to help him tune his SIEM, a seemingly harmless request. As the conversation progresses the SE thinks the guy is sketchy so he contacts the SOC. The SOC runs a number of checks on the accounts and checks for any relationship to any known incidents, nothing is found. Guidance given is to limit the scope of information given to the individual per the company guidelines. So what’s next? Well, if we abide by the 3rd rule, this information would get shared with the Intel team, and then the 4th rule takes effect, the information is recycled. It is sent through the Intel Team that runs through it with a different filter and they begin to identify that not only is the individual sketchy, he is possibly even an imposter executing a very crafty social engineering attack. So what’s next? Recycle & Re-Use again. Contact the customer that the individual claims to represent and pass the information to them. Let them look at it with a different filter. You never know what puzzle someone else is putting together and what appears to be “nothing to see here” might be a critical piece of information that ties everything together for someone else.

SUMMARY:
The first part of this article discussed how traditional, rigid, corporate sandboxes of responsibility that define various IT functionalities within an InfoSec program have a tendency to do hinder effectiveness when it comes to security. The second part of this article provides some ideas and examples on how to restructure and build teams as well as ideas on when/how share information across specialities. There are a few takeaways I’d like to leave you with:

1. The only right structure, is the one that maximizes and encourages information sharing and meets the organizational needs for security AND intelligence within resource constraints

2. Embrace failures – they are the stepping stones that lead to the door of success

3. Bring your teams (worker bee level) from all disciplines, together regularly to discuss all kinds of security concerns and issues everyone is experiencing – and most of all encourage them to SHARE ideas and experience.

4. Recycle data on security incidents, even concerns of a possible incident. Ensure they are passed amongst your teams via a process that works for your organization, with the end goal of everyone getting a say-so/review of it.

So go forth, do great things, and enjoy the InfoSecsy side of security not just the InfoFail side.

Thank you once again for taking time to read OSINT Heaven’s Blog.

Stop Having Sex for the First Time – part 1

As someone who’s been working on an OSINT project lately, I’ve had many surprises and hurdles because there’s poor organization to our execution and little to no information sharing between security functions in the same department. I recently got access to a very important piece of information/tool that resulted in a huge discovery…..this is Oct, we’ve been working on this since July…. Unfortunately, this problem is not unique to this project, OSINT or InfoSec.

THE EXAMPLE:

The US Army structured a communications battalion with companies, made up of platoons/teams/squads etc.  and basically the personnel all had the same functional training background. One company, 30-100 people, would be folks who operated/maintained satellites, another knew cabling and wiring, another radios, and another of those skilled in networking/network communications. Whenever the battalion would go out to train, they would take a few people from each company throw them together like a patch quilt so as to have someone capable of each required skill for the mission. They’d send these patch quilt teams out to different locations with some training objective (usually to successfully establish a communication link, keep it up, and practice for war).

The teams contained the best of the best, people of varying skill levels, and competent (minus the token derp). Nonetheless, despite these groups being highly trained w/ above average intelligence, their execution was clunky, fluidity was all but present and they flat out struggled every time to meet the objective. Why? A few basic reasons (this list is not exhaustive) – nobody knew each other, we communicated in different ways, we could not anticipate each others needs or actions, there was no rhythm no synchronization. It was like being a virgin having sex for the first time every time, with another virgin. Sure, we got the job done, but it was rarely every “awesome”.

So the heart of the problem – teams, functions and activities were silos, not circles. Instead of being an elegant woven silk tapestry full of vibrant colors, we were a hideous patch quilt.

THE INFOSEC PARALLEL

We have the same problem in “Information Security” teams. There’s the Network Security Team, The Security Operations Center, and if you’re luck there is/are Pen Test, Intel, Forensics, and Malware team(s). So with all this awesomeness under one roof how could we possibly fail?

  1. Leadership Roadblocks – Managers sit in rooms making drug deals over resources and designing processes in vacuums.
  2. Lack of Communication/Sharing – None of the worker bees comes together on a regular with information to share, the “intel” that everyone needs.  Instead, data gets passed around/tracked in one ticketing system from workflow to the next team’s workflow if we’re lucky (and documentation usually sucks).
  3. Pissing Contests – we’ve got the “you will use *MY* ticketing system” mentality
  4. Lack of Integration – Let’s not forget that we’ve got all the awesome teams, and we’ve spent money (millions) on awesome tools and not a dime to integrate them, so “intel” sits hidden or is nearly/impossible to gather.
  5. That’s MINE! – Network “Security” teams don’t let anyone have read access to network logs (and only send silly/useless globs of syslogs to a SIEM), only the Help Desk is allowed to have remote access to a host even when a user contacts a SOC suspecting compromise of their host.
  6. Black Holes – Forensic team takes a compromised drive/image that the SOC quarantined and runs away to their cave never to be seen again, the malware team pops their heads up like a prairie dog when you say malware, you feed them and they run away only to pop out of another hole and say here’s your IoC and scurry down the hole.

Instead of being a highly functioning ecosystem of intelligent wild animals (face it, real InfoSec folks we’re just wild :), we’re a damn zoo and none of the animals get to play together.

OK….hopefully you get the point by now – We ALL play a part in this.

SURPISE! – Not really

So is it any wonder when there’s an attack on your organization that everyone flounders to some degree and for the serious ones you simply have to call someone in? [In all honesty, sometimes that actually IS the best and most responsible thing to do]. Is it any surprise that after the attack, all you do is prepare for the next one and you never really figure out anything behind it?  You never really operate in a preventative or offensive fashion.  You just sit around waiting for the next bully to steal your lunch.

So I ask, do you really want to keep having s3x the first time every time? I mean – practice **IS** supposed to improve performance thus making the experience better and better. Sure you have processes, that’s great & flow charts are awesome, but it only gets you so far. The SOC does it’s own little training on “here’s how we RESPOND to ABC incident” the NetSec-Ops team is doing their own RESPONSE training as is every other team that plays some role in a RESPONSE effort. The funny thing – the Windows/Unix/Server/App teams have a part too, but they’re never part of the training and nobody is invited to participate in the other team’s training.  BTW: where is all the info from your “lessons learned” going and where’s your “intel” sharing so you can start PREVENTING instead of just RESPONDING?

Back to our example….

The Army realized the shortcomings of their structure and began restructuring their communications units. They reorganized so that the groups that would fight together would not only train together, but live and work together. Battalions had companies that consisted of platoons with personnel from all the skills needed to be successful. These soldiers worked together every day, even began to learn about each other’s jobs. Light bulbs started going off, greater understanding and better communication emerged. They began to bond, to learn each other’s likes/dislikes, communication nuances, they began to execute with precision and efficiency. They began looking more like that expensive beautiful tapestry and acting like life long lovers.

So how could a company do this?

Well there is no one cookie-cutter solution that will work for every company, but here’s one novel underlying theme – locate them together physically if possible, gather them virtually at minimum. Granted there needs to be separation of duties and permissions, but that doesn’t mean you must have silos. Let the worker bees ACROSS GROUPS work together to define processes and make suggestions up through management. If that’s not possible, have regular working groups (weekly preferably) where they all get together. Sometimes the meetings will be intense with lots of hot topics/issues, other times they’ll have coffee and just bonding, but get them together

Another idea, Wherever your largest team is, usually the SOC, have seats for a NetSec, Malware, Forensics, and Intel Team members to work. The teams can rotate out who works over there, but have someone over there for 2-4 weeks at a time, let them “live & fight together”. Let them share information, watch the people that are part of your processes begin to work more effectively.

In the end, the goal is to have your team execute like they’ve been giving it to each other their whole life, not fumbling through sex like virgins for the first time, every time you need to respond to an incident. Then comes the next step, pillow talk the morning after – or sharing coffee and a bagel if you prefer.

Stay tuned for Part 2 where I’ll be talking about how to maximize this architecture for an intel team.

Words Matter

One of the single most important techniques/activities when gathering intelligence (i.e. intel) from open source repositories is analytic reading. The second is properly presenting data/intel with relevant context.

ANALYTIC READING

This isn’t the kind of reading you do in the summer with a children’s book and litter of rug rats gathered at your feet, this is the kind of reading one does where you look for hints or clues about a person based on phrasing or word choice. Now you don’t need to have a degree in psychology or grammar to do this, you simply have to pay attention, take notes, and apply a little common sense.

Let’s take my request for help from the #InfoSecFam on ideas for my first blog. Here were the responses I got (thank you to the brave souls who dare support me) :p

  1. Well, you could start with those lovely examples of people posting pics of credit cards…
  2. Then folks posting about going on vacation on their facebooks…
  3. Maybe some military types posting pics with intact exif?
  4. <graphic> #internetfeds
  5. google hacking is still incredibly viable, and it’s a huge OSINT fail.
  6. specifically anonymous FTP servers indexed by google.
  7. <graphic> bad admins everywhere. Really bad. Ive seen some sh1t man
  8. Boarding passes are now a big thing… “I Know Where You LIve: all the sh*t that people post”
  9. You could do reviews of OSINT web-tools
  10. ok, an oldie being forgotten, ‘don’t run with admin/root’.

Just a Little Intel…

So, let’s analyze what we’ve read. [Note this example is very trivial, however the principles presented are not.]

  • Q1: What’s the culture/industry of the authors here?
    • A1: #InfoSec
  • Q2: What are underlying characteristics of this group’s communication styles?
    • A2:  InfoSec culture is heavily sarcastic
  • Q3:  Are there clues to anyone’s profession/hobby listed in these comments?
    • A3:  Yes – acronym and word choice: FTP, intact exif, bad admins everywhere, ‘admin/root’
  • Q4:  Any clues to age or experience?
    • A4: Yes –  still incredibly viable, oldie but goodieI

The list of questions above is a trivial example of how to glean the not-so-obvious intel that is implied.  Nonetheless, the questions asked and answered, should be driven by a few things, two at minimum: a profile template and a threat model [otherwise you’re out there going all Willy Nilly and traipsing through minefields of soggy cow patties.]  SO! Before you even start gathering Intel, your leadership should have identified WHAT they want to know (identified in the threat model) and HOW you will collect it (defined in the documentation standards and profile template).  So as you do answer these very valuable questions, you’re looking for the same data points, all the time, essentially filling in the pieces of a puzzle one at a time.  Keep in mind, they may not all be present, but at least you’re looking for them.  As you get them, you should be capturing them in a profile template.

The list of questions could go on and on depending on how much of the ocean you’re planning on boiling, and tools such as the IBM Tone Analyzer (demo link here) or the IBM Personality Analyzer can offer valuable insight as well, but tools are no replacement for instinct.  While these tools may enhance or even expedite the analysis process, they cannot replace an Analyst’s instinct and skills of discernment as they read something and decide what “box” to put it in, if it is relevant, indicates personality traits, warrants in/exclusion or is a thread that needs to be pulled to see what else unravels.

Takeaway:  Read closely, carefully, and never under estimate the human factors at work.  Read between the letters AND the lines.  You may find clues you need when building a profile or finding a target simply by the nuances in their tiniest commentary.

RELEVANT CONTEXT

So let’s talk about the biggest mistake with the list…. It’s in numerical order! If you were only reading this an OSINT report, you might think these came from 10 different people or one person provided 10 ideas. So, by creating a pure LIST of comments rather than a LIST with logical grouping, we lose context because multiple comments were made by some of the same individuals,

Let’s fix that….

P1-1. Well, you could start with those lovely examples of people posting pics of credit cards…
P1-2. Then folks posting about going on vacation on their facebooks…
P1-3. Maybe some military types posting pics with intact exif?

P2-1. <graphic of chat> #internetfeds
P2-2. <graphic of man hiding in a chair> bad admins everywhere. Really bad. Ive seen some sh1t man (BTW @MyTinehNimjeh I <3 u man LOL)

P3-1. google hacking is still incredibly viable, and it’s a huge OSINT fail.
P3-2. specifically anonymous FTP servers indexed by google.

P4-1. Boarding passes are now a big thing… “I Know Where You LIve: all the sh*t that people post”
P5-1. You could do reviews of OSINT web-tools
P6-1. ok, an oldie being forgotten, ‘don’t run with admin/root’.

Now you see there were actually 6, not 10 people who replied (P# meaning Person 1, Person 2, Person 3…-1, -2 being the comment number they made).

Additionally, this context represents something else taken for granted by the statisticians an API monkeys – it isn’t always the total volume that matters, sometimes it’s the volume of one person, or even the lack of replies to others who may have forked a conversation thread.  If this thread were listed as a statistic, stating that there were 10 comments, that too would also be incorrect.  There were actually a few different forks, some took a humorous path, others were simply “neutral” suggestions, AND there were more than a total of 10 interactions.  This list however, only represented those comments that were actually relevant to the request for help with ideas which were extracted and placed in this article.  Again, in your OSINT reports, ensure you represent relevant intel accurately, and provide the reader proper context through commentary and presentation.

Takeaway – ensure that HOW you present data in a report represents it with as much relevant context as possible.