Security+ Journey – DNS for Recon

For attackers and defenders, tools are very important. If a threat actor does not know much about a potential target, they will need to perform some reconnaissance. There are many tools out there that can be leveraged for recon, some of which are readily available on popular operating systems. These tools are not necesarily built with a purpose of reconnaissance as a goal, but they can be used that way. One way for a threat actor to find out more about a target domain is by levearaging the Domain Name System (DNS). There are many different types of DNS records that can provide some insight about what a potential target has on their network. By nature of systems that leverage TCP/IP, computers need to be able to find out the IP addresses of the destination systems with which they are attempting to communicate. At a high level, DNS is used to translate familiar names into IP addresses, in a client/server model. This keeps us humans from having to memorize IP addresses of websites and the like, keeping both private and public networks (the internet) usable and dynamic. Tools such as nslookup (Windows), dig (Linux), and dnsenum can be used to query DNS servers to gather information about domains.

Now, let’s take a look at the nslookup utility within Windows to see what some of the options are that exist within the tool. First off, to run nslookup, just open up a command prompt, type nslookup and hit the enter key. This will take you into the nslookup prompt. First, we can look at the existing settings within the utility using the set all command.

Output from the set all command.

An option of note listed above is the type option. This sets the type of query that will be performed. You can see above that it is currently set to the default of A+AAAA, so it will query for IPv4 and IPv6 A records. The available options are: A,AAAA,A+AAAA,ANY,CNAME,MX,NS,PTR,SOA,SRV. To change the record type, you can enter set type=<record type>. Another option, that could be potentially used for reconnaissance is the all type. If you enter set type=all (then hit enter), then enter a domain name to query; if the server allows it, it will return the answers of all records in that DNS zone. This type of query can be thought of as a zone transfer.

Once the settings are configured the way you want them (oftentimes they can be left default if you are just wanting to query basic A records), you are just about ready to query a domain name. Sometimes, when it comes to troubleshooting potential DNS issues, perspective is key. When record changes are made, especially to public facing DNS servers, by nature of time-to-live (TTL) values, it can take ptotentially a considerable amount of time for a record to change to reach global DNS propagation. You may want to query different local or public DNS servers to see how they are resolving the record in question. That could explain why a record is resolving correctly for some users that point to DNS server #1 and incorrectly for other users that point to DNS server #2. Within nslookup, to change the server you want to query, you just type server followed by a space, followed by the IP address of name of the DNS server that you want to query (then hit enter). Finally, to query a record, you just have to type in the name of the record (as a fully qualified domain name) and hit the enter key. If the DNS server you are pointing to is able to resolve this record to an IP address, you will the result on the screen.

Leveraging DNS query tools such as nslookup, dig, and dnsenum can absolutley be used as methods of gathering reconnaissance by threat actors. Having a list of records from a target domain could give the threat actor information about services the target is running, or in the least, a list of devices to scan for open services and/or vulnerabilities.

Security+ Journey – Attack Surface and Vectors

One thing is certain in terms of cybersecurity. Attacks will and do occur regularly. While security is the responsiblity of all employees in an organization, active defense is up to IT and Info Sec teams. One way to help defend organizations effectively and efficiently is to understand the existing attack surface and potential attack vectors that exist for attackers to exploit. Essentially, these are the points of attack and paths that attackers can take to infiltrate networks and systems. We will unpack and describe these terms in the rest of this post.

Attack Surface
As brought up in the opening paragragh, the attack surface is comprised of the different points in a network or system that are open for connections. For example, these points could be application servers that provide a service to customers and employees. While these connections are necessary to serve business purposes, they can also potentially be exploited by attackers. In order to properly defend networks and systems, it is imperative to have an inventory and understanding of the attack surface. You cannot effectively defend what you do not know even exists.

Attack Vectors
While the attack surface describes the potential entry points into a network or system, an attack vector is the specific path taken by a threat actor to attack a sytem. For a contrast example, while an open web server is in the attack surface, the HTTP/HTTPS application port/service would be the attack vector. Attack vectors describe the method or direction taken by a threat actor to exploit a vulnerability. Examples of potential attack vectors include:

  • Direct access
    • The direct access vector describes the ability for attackers to gain physical access to a system. This would be like someone being able to walk up to an unlocked workstation and gain unauthorized access to a system.
  • Removable media
    • A great example of removable media as an attack vector is a small, USB flash drive. Flash drives are great tools for storage, but can be easily exploited as a means of attack. If you do not know for sure what is on a flash drive, it is dangerous to plug it into a system. We often hear examples of pen tests or experiments at security conferences in which flash drives are strategically left around unattended or actively handed out to see if people will accept them and plug them into their workstations.
  • Email
    • Email has to be one of the largest attack vectors out there, and has been for some time. Phishing schemes are very prevalent and prove to be a relatively low effort vector for attackers. If malicious emails can get past security controls, they can inflict major damage.
  • Remote access
    • Remote access is similar to the web server example I gave above. Remote access provides us the ability to gain access to systems when we are off-site. While it is very useful, it has the potential to be exploited by attackers as well.
  • Supply chain
    • Supply chain is an attack vector that has gained popularity in recent years. Often as consumers, we place trust in the companies from which we purchase goods and services. The same is true for businesses. Businesses are also consumers of goods and services from other companies. Attackers can leverage that supply chain to infect and infiltrate customers of these services. If a threat actor can inflitrate a product that has many consumers, they have the ability to potentially infiltrate or infect those consumers as well.
  • Social media
    • Social media as an attack vector, to me, is a bit different than the other examples here. Rather than leveraging social media to gain access to or infect systems, it can be used to maliciously influence people or provide disinformation as an influence campaign.
  • Cloud
    • Just because services get hosted and leveraged in the cloud, does not mean that security concerns go away. There is a shared responsibility model with cloud computing. The cloud service providers are responsible for security of the cloud, and the consumers are responsible for security in the cloud. There have been many stories of security researchers finding unsecured cloud databases on the internet. Cloud is very much a viable attack vector.

It does seem that when it comes to cybersecurity, the decks are often stacked against the defenders. There is a saying that I’ve heard before that goes something like, defenders have to be constantly ready and successful; attackers only have to be successful once to gain access. While information security can prove to be challenging, we are in much better shape when we are aware of the attack surface and potential attack vectors that attackers can leverage.

Featured image credit: Tomáš Malík

Security+ Journey – Lions, Tigers, and Bears

Yeah I know, I went for the catchy title to try to draw you into reading this. However, when looking at the topic of vulnerabilities, threats, and risks in my list, the title above is what came to mind. Thinking through it though, that title seems to work. Vulnerabilities, threats, and risks are all scary things we have to consider and account for. Now, depending on where you live, lions, tigers, and bears may not be as applicable in your daily life as vulnerabilities, threats, and risks, but I think you get the idea. Actually, as I write this, I’m going add a fourth scary thing in the world of information security; exploits. Yes, that throws off my title name, but I feel like I’m on a roll here so I am just going to run with it. Let’s equate exploits to spiders just for fun. Those things are terrifying, right? In the rest of the post, I will give some descriptions around these four items.

A vulnerability is really just a weakness in an application, hardware, or system. From a cybersecurity perspective, it is something that can be leveraged for malicious purposes. Another way to put this is that a vulnerability can be exploited.

I think it is easy to not necessarily confuse the concepts of vulnerabilities and exploits, but it is definitely easy to think about them in the same vein. Which makes sense, because they are definitely coupled together, so it’s possible to potentially confuse the meanings. As stated above, while the vulnerability is the weakness or the actual issue with the application or system, the exploit is the tool or method that is used to take advantage of, or attack that vulnerability. For a practical example, you may hear that a vendor has issued a statement that they have a known security flaw in their product (and hopefully also have a patch to fix that flaw). The security flaw itself is the vulnerability. Now, if it is also announced that there is a known attack method in the wild that is able to leverage this vulnerability for malicious purposes, that attack method would be the exploit.

When it comes down to it, threats are potentially bad things that you are trying to avoid or protect against. Further, threats are individuals, groups, actions, or behaviors that could cause harm to the organization. Keep in mind that this list of items could lead to either intentional or unintentional harm. As we all know, accidents happen, and we want to be cognizant of those as well.

How I like to think of this, is that the previous terms vulnerabilities, exploits, and threats are all factors in the calculation of overall risk. To me, a large portion of cybersecurity is risk management. We need to be able to determine which activities pose the most risk to the organization and work toward mitigating and managing that level of risk. Risk is the probability of a vulnerability being exploited by a threat, along with the level of impact that will be caused to the organization.

In my opinion, a big part of cybersecurity is constantly being aware of the potential bad things that can happen so you can put controls in place to mitigate and minimze the risk/impact of those bad things. At least there are clear definitions out there to help us understand and deal with vulnerabilities, exploits, and threats, and use those explanations and concepts to help us calculate the overall risk.

Featured image credit – Rasmus Svinding

Security+ Journey – Functional Types of Controls

Security controls are put in place ultimately to mitigate and minimize risk for an organization. As covered in a previous post, there are three main categories of security contols. To recap, these categories are technical (logical), operational (physical), and managerial (administrative). While these categories give us an idea of the high level characteristics of the different groupings of security controls, in this post we will take it a step further and highlight the different functional types of security controls. I interpret the functional control types as describing what role the control is serving and how it is being implemented. There are three main functional control types and three of what I call “sub-types”. As listed below, the first three are the main types.

A preventive control is put in place to do just what the name implies; to prevent an attack from occuring or a vulnerability from being exploited. From a sequence/time perspective, a preventive control is active before a successful attack can occur. Examples of preventive controls, listed alongside their corresponding control categories are access control lists (technical), next generation firewalls (technical), standard operating procedures (managerial), and security guards (operational).

Detective security controls identify and track events as they happen. Detective controls get the most use during an event. Events are tracked through logging and can be alerted upon as well. Examples of detective controls, listed alongside their corresponding control categories are logs (technical), motion sensors (operational), and intrustion detection systems (technical).

Corrective security controls are put in place to mitigate or minimize the impact of a security event. Examples of technical, corrective security controls are backup systems, patch management systems, and anti-malware software.

The purpose of physical security controls are to protect again in-person attacks and malicious attempts at access. Examples of physical controls are doors/locks, alarms, lights, and phyical security (guards).

Deterring security controls discourage individuals from doing something that is unauthorized. Typical detterent controls include signage, lights, and fencing.

A compensating control can be thought of as a backup or secondary control. This would be something that replicates a primary control in case of failure of the primary control, or something that provides added protection if the primary control does not fully meet the requirements. An example of a compensating control would be a configuration or system backup. If a system becomes corrupted or wiped, it can be restored from the backup, if one exists.

Security controls help us to mitigate and minimize risks. As listed above, there are different functional types of controls that can help us to understand the purpose of the controls and which may be needed to support the security policy and posture of the company.

Featured image credit – Travis Saylor

Cloud Essentials+ Journey – Try Before You Buy

Wouldn’t it be great if everything we wanted to purchase and integrate into our technology stacks would just work the way we wanted without needing to worry about it or even test things out? Well, anyone who has been around technology knows that is not the case. There is not always a ‘one size fits all’ technology that is going to meet the need for every organization and use case. We need methods to be able to evaluate new technology products and systems before we take the plunge of purchases to ensure that the given tech is going to be a good fit for the organization. Luckily, we have multiple means available for accomplishing this ‘try before you buy’ concept when it comes to evaluating new products and services. The options we have are proofs of concept, pilot programs, and proof of value studies.

Before we dig into each of these product evaluation options, let’s start where I often like to, which is with requirements. If we do not begin with a clear picture of what it is that we are trying to accomplish, it is going to be very difficult for us to definitively determine whether the evaluation is a success or a failure. These requirements or outcomes that we are trying to achieve in these evaluation programs are called success criteria. Having defined success criteria gives us a guide to perform and analyze a proper evaluation. Now, let’s touch on the different evaluation options listed above.

Proof of Concept
In my opinion, the proof of concept (POC) is going to be the lowest lift, and minimally intrusive evaluation option for a new technology. The purpose of a POC study or implementation is to just verify that a new product or service functions as advertised for the specific use case in question. Depending on the technology being evaluated, combined with the use case in question, a proof of concept could be a relatively small effort. Most likely in a POC, we are not going to be delving too deeply into the details of the product or performing a lot of stress testing. We are really just wanting to answer the question of “Does this product, at a high level, do what I need it to do?”. For more in depth evaluations, we look to implementing a pilot program.

Pilot Programs
As introduced in the section above, pilot programs really take the POC a step further. A pilot program is going to get more people involved in evaluating a potential new solution. A subset of users would be selected to test out the new product over a period to time to perform that in depth analysis and stress testing that was mentioned to not necessarily take place in a proof of concept study. Some key points and tasks that should be part of a pilot program include:

  • Defining objectives.
  • Carefully select the participants. These should be individuals that would be key users, or power users of the system if it is purchased and integrated into production.
  • Have a clear test plan defined to make sure the success criteria of the pilot program are met.
  • Have known methods defined for communicating and delivering feedback throughout the pilot program.
  • If the product ends up getting purchased, make sure to use the lessons learned from the pilot, when deploying the system into production.

Proof of Value
At face value, I think a proof of value (POV) study can be somewhat nebulus. The goal of a POV study is to come to a decision about whether or not implementing a new technology solution will add value to an individual process or the organization overall. We need a way of quantifying that value into terms that make sense such as cost or time savings. In my option, this definitely means getting the proper business units involved to make sure this value calculation is as close to reality as possible.

While proofs of concept, pilot programs, and proof of value studies take time and effort to complete, we would really be doing a disservice to the organizations we represent if we did not go through the due diligence of proper evaluations before purchasing new technology solutions. The evaluation concepts described in this article give us those different options to try before we buy.

Featured image credit – Magda Ehlers

Security+ Journey – Control Categories

Large concepts within information security are understanding what protections/controls we should have in place and then the actual processes of implementing those controls. The reason we have security controls can point back to the concept of the CIA Triad. To keep our organizations safe and healthy from an information security perspective, we should ensure that our data and systems are kept confidential, have integrity, and are available for use. Implementing security controls can help us align with the principles of the CIA Triad. That being stated, it might be easy to think that since we are dealing with information security, that we are only concerned technical controls and protections such as firewalls and anti-malware solutions. While those and others like them are important, that is not all there is when it comes to categories of security controls. The three main security control categories are technical (logical), operational (physical), and managerial (administrative). Let’s delve into these to get a better understanding.

Technical controls (also known as logical controls) are those that I mentioned in the first paragraph. These are the security controls that are implemented as hardware or software IT systems. Examples of technical security controls are firewalls, anti-malware solutions, web filtering, multi factor authentication (MFA), and email security products.

While technical controls are implemented as hardware and/or software solutions, operational controls (also known as physical controls) are implemented by people. Examples of operational controls are security guards, door locks, motion sensor activated lighting, and ongoing training.

As with many things, in order for a system or process to remain effective, we need ways to audit it over time. That is where managerial controls (also known as adminitrative controls) come into the picture. Managerial controls give oversight of, or auditing platforms for information systems and processes. Examples of managerial controls include security policies, ongoing testing such as test phishing campaigns, change control processes, and of course, auditing processes.

There are many ways for us to protect the information security of our organizations. Not just technical controls are in scope. There are also operational and managerial controls that can be put in place to help ensure confidentiality, integrity, and availability.

Featured image credit – George Becker

Cloud Essentials+ Journey – Statement of Work

In a previous post in this series, we covered different request documents that are sent to vendors/partners/service providers such as the request for information (RFI), request for proposal (RFP), and request for quote (RFQ). These request documents all deal with different phases of the pre-procurement process of a technology, system, or application. There is another vendor/partner related document of note that is more geared toward the sales/post sales side of the procurement process. That document is called the statement of work (SOW).

A statement of work (SOW) can be thought of as a project management document. A SOW is generated by a partner organization or service provider when a business is purchasing a solution which includes an implementation effort from the partner organization/service provider. The purpose of the SOW is to paint a clear picture of what the customer is purchasing, and how the partner organization will implement said solution. This gets both parties on the same page to agree upon the work to be completed and the success criteria to ensure that expectations are met. In general, the statement of work will include the following information:

  • High level need and scope of the project.
  • Detailed steps of tasks to be performed, including the schedule or timeline.
  • Success criteria. This should include a clear representation of what “done” means. What has to be completed and agreed upon to consistute a completed project.
  • Billing information.

In my opinion, a statement of work (SOW) is not just trivial paperwork. A well done and agreed upon SOW is a vital component of a successul project. We cannot just assume that everyone involved has the same understanding of what needs be done and why. A statement of work displays all of this in writing so that all parties involved have a clear picture of the solution that was purchased, how it will be implemented, and when.

Security+ Journey – Five Info Sec Functions

Something that I really appreciate when learning something new or working with a new technology is a clearly defined concept. When learning basic cloud concepts as part of my Cloud Essentials+ journey, I relied on the definitions from NIST to set the groundwork of my understanding of cloud computing characteristics. Well, NIST was there for me again, right away at the beginning of my Security+ journey. NIST has defined five functions of info sec/cybersecurity tasks. To me, this is helpful in building an easily reviewable understanding of the the responibilities of security teams and programs. Those five functions are identify, protect, detect, respond, and recover. In the rest of this post, I will give a description/my interpretation of each security task function.

The definition that I had come across in my my studies for the identify security task function, was not what I had expected. I was originally thinking this function was going to be about finding and categorizing incidents and issues in real time. It turns out that is more of a detect function that will be covered later in this post. The identify function is more about designing and developing policy, and plans for mitigating risk. With this function, security teams are building their security policies and programs. They are researching and understanding vulernabilities, threats, and risks, and then suggesting mitigating controls to reduce that risk.

This function really brings to light the fact that all employees of an organization, especially within the IT/Security departments, are responsible for information and cyber security. The protect function is all about managing a lifecycle of IT systems and assets with security as a underlying requirement from the beginning, rather than being an afterthought. Building and maintaining systems with security and hardening best practices documented and in play, will help to protect the organization.

The detect function is all about continuous and effective monitoring, reporting, and notifying, in regard to IT systems. Security controls should be able to detect anomolous behavior, then notify the proper teams to take necessary action. These security controls also need to be able to adapt to changing threat landscapes by remaining up to date on vulnerabilities, threats, and risks.

In my opinion, the respond function goes hand-in-hand with the detect function. I am thinking that in the respond function of cybersecurity, we are taking the inputs that we receive from the detect function, and acting on them. With the respond function, we are performing analysis on data received from the detect function and then performing mitigating actions in response to treats.

The recover function addresses having plans in place to restore IT systems when certain events are not mitigated and downtime is caused. As much as we want to be able to mitigate as much risk as possible, we need to be prepared and have plans for next steps to restore systems and data when they are tampered with or taken offline.

I believe that realizing and understanding these five functions of information security can help in understanding the responsibilities of security teams and programs. As stated earlier, I like to have clear definitions because they not only help me find where to start when dealing with something new, but they also help me to know what specifically is in scope to reduce the risk of me missing something important.

Cloud Essentials+ Journey – Licensing Models

One major shift to migrating to cloud services was the move from capital expenses to operating expenses. With capital expenditures, we typically pay for assets up front, and own and maintain those assets. On the other hand, with operating expenditures, we are paying for a service, or furthermore, the right to use that service/application/system. Services that leverage operating expense models rely on licensing. When we purchase technology services today, whether they are cloud hosted or not, we are often going to be dealing with licensing. There are three major types of license models: perpetual, subscription, and Bring Your Own License (BYOL).

Perpetual Licensing
A perpetual license is a one-time-purchase license that gives you the right to use the service/application/system for the lifetime of that application. There is no recurring cost with this license model.

Subscription Licensing
Subscription licensing is becoming more and more common as we adopt and consume more cloud services. In contrast to perpetual licensing, with subscription licenses, we incur ongoing, recurring costs to use the given the application. Typically subscription licensing will need to be purchased on a monthly, yearly, or multi-year basis. This will depend on the available contracts of the service.

Bring Your Own License (BYOL)
The goal of the BYOL model is to bring flexibility to purchasing licenses. BYOL licenses are meant to be able to be used either in an on-premises or cloud environment. For instance, if you have a software license (that is of the BYOL type) applied to an application running in an on-prem data center, you can move that application to a cloud hosted server and be able to leverage the same software license without having to re-purchase the license.

Licensing, especially of the subscription type is something that many of us are getting familiar with on a daily basis. We levearge subscription-based licensing services for products like collaboration applications, streaming video, and streaming music. It will be interesting to see how licensing and license models evolve and change over the years.

Featured image photo credit – A.J. Murray

Security+ Journey – CIA Triad

As with dealing with practically any task, project, or initiative, having a set of guidelines to assist us toward our goals can be very important and beneficial. Information security is no different. Just looking at and thinking about the words information security can be a bit daunting and overwhelming. Where do we even start when it comes to designing and implementing secure networks? That is where beginning with some guidelines can help. In working with Info Sec, there is a common set of guidelines we can look to, to assist us, called the CIA Triad. No, not that CIA. This CIA acronym stands for confidentiality, integrity, and availability. These high level components can be thought of as pillars when creating security policy and implementing security controls. Let’s unpack the components of the CIA Triad.

In my opinion, confidentiality covers two high level, yet tightly coupled concepts. The first is around keeping data private, and the second is around ensuring that only properly authenticated and authorized individuals have access to the data in question. When I see the term data privacy, my first thought is encryption. We need to make sure that certain data, whether it is in use, in transit, or at rest, is kept private. As soon as data that is deemed to be private is in clear text, especially in transit, that’s when we have issues. Having encrypted data is great and important but we also need to take it a step further. We also need to make sure that not just anybody has the ability to access, view, edit, and delete the data. Data deemed confidential or private should be secured by authentication and authorization. Only known, authorized individuals should have access to the data.

Data integrity is all about trust. Ourselves and our customers need to be assured that the data is trustworthy; that is has not been modified by unauthorized parties. From a practical application standpoint, technologies such as hashing and checksums are used to help ensure that the data has integrity and can be trusted.

Applications, systems, and services are no good to anyone if they cannot be accessed and used as they were intended. Security controls should be applied to prevent systems from going down or offline. The concept of security to promote availability does not apply to just the cyber realm. Security from an availability standpoint also applies to physical concepts such as potential power loss or weather events. Any issue or event that could impact the availability of a system can be thought of as a security-related concern.

Another concept that can go along with the CIA Triad is non-repudation. This is a term that I had not heard before starting my Security+ studies. Non-repudiation means making sure that the identity that created and/or sent data remains associated to that data. The purpose of this is to prevent the identity from successfully denying that they indeed created/sent the data. Essentially, I think this proves the need for logging and correlation.

I think that the CIA Triad gives us a good starting point when building and auditing security programs. We need to make sure that we can keep our systems and data confidential, with integrity, and available. Also, as a closing thought, I found that this model can be referred to as AIC to remove confusion from the other common acronym of CIA.