SourceFire IPS - Understanding Inline Deployments

Understanding how your SourceFire Sensors (or any other IPS for that matter) are deployed is very important to the results you can expect from the device(s).

In this post, I will focus on providing clarity on some of the things you should be aware of when configuring your SourceFire IPS to be inline.

First off let's  understand what is meant by inline deployment. In an inline deployment, the IPS device sits between two network devices. Typically, this would be a perimeter firewall which connects the internal network to the Internet and an internal device such as a switch which connects the devices in the local LAN to the perimeter firewall as shown below.
In the diagram above, the eth0 and eth1 on the sensor forms an inline pair through which the traffic will flow between the switch and the firewall. This is the first step in a successful inline deployment.

Now that our device is inline, we need to configure our IPS Intrusion Policy to "Drop When Inline"

Final step is to select the relevant rule and ensure "Drop and Generate Events" is specified for the rule 

Below shows the options available for configuring rule state.


Below shows an example of a rue which has been configured to "Drop and Generate Events". Note the red "X" at the end.


As this post has shown, to truly achieve IPS functionality, you need to not only have your device inline but also to configure both the policy and the rules.

Hope you enjoyed reading this post. 

PFSense + Splunk - Security on the cheap - Parsing DHCP Server Logs

Continuing with the Splunk dashboards, let's add a panel for parsed ARPWatch logs

Sample DHCP Server Message

May  2 20:15:14 192.168.0.1 May  3 00:15:06 dhcpd: DHCPACK on 192.168.0.14 to cc:55:ad:1a:2b:c5 via dc0

Our Search Filter:
"dhcpd:" | rex field=_raw "dhcpd:\s(?<dhcp_message>[A-Za-z]*).*\s(?<ip_address>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}).*\s(?<mac_address>[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2}).*\s(?<interface>.*)" | stats count by ip_address, dhcp_message, mac_address, interface

Our Results:




Similarly to the previous posts in this series, being able to monitor your DHCP activity can help add context to your network, putting you in a better position to decide how to move forward.


In this series:
1. PFSense + Splunk - Security on the cheap
2. PFSense + Splunk - Security on the cheap - Parsing Firewall logs
3. PFSense + Splunk - Security on the cheap - Parsing ARPWatch Logs
4. PFSense + Splunk - Security on the cheap - Parsing Snort Logs
5. PFSense + Splunk - Security on the cheap - Parsing DHCP Server Logs

PFSense + Splunk - Security on the cheap - Parsing Snort Logs

Continuing with the Splunk dashboards, let's add a panel for parsed Snort logs

A Snort alert message looks as follows:
Apr 22 16:33:30 192.168.0.1 Apr 22 20:33:03 snort[64690]: [119:2:1] (http_inspect) DOUBLE DECODING ATTACK [Classification: Not Suspicious Traffic] [Priority: 3] {TCP} 192.168.0.11:49917 -> 72.251.227.249:80

To build out our Snort Monitoring Panel, the following search filter will be used:

host="192.168.0.1" snort NOT "/usr/sbin/cron" | rex field=_raw "\ssnort\[[0-9]*\]:\s\[(?<snort_sid>[0-9:].*?)\]\s\((?<snort_preprocessor>.*)\)\s(?<snort_message>.*)\[Classification:\s(?<snort_classification>.*)\]\s\[Priority:\s(?<snort_priority>[0-9]{1})\]\s\{(?<snort_protocol>.*)\}\s(?<src_ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}):(?<src_port>[0-9].*?)\s\-\>\s(?<dest_ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}):(?<d_port>[0-9].*)" | stats count by snort_sid, snort_preprocessor, snort_message,  snort_classification, snort_priority, snort_protocol, src_ip, src_port, dest_ip, d_port | sort snort_priority

Results from our search


Why would this information be helpful? If you are using a centralize dashboard for all your security monitoring, the panel can give you the insight as to what is going on in your network. You can then go directly to your Snort device to dig a bit deeper or to perform further analysis.

Hope you find this helpful and see you in the post on Parsing of ARPWatch Logs

In this series:
1. PFSense + Splunk - Security on the cheap
2. PFSense + Splunk - Security on the cheap - Parsing Firewall logs
3. PFSense + Splunk - Security on the cheap - Parsing ARPWatch Logs
4. PFSense + Splunk - Security on the cheap - Parsing Snort Logs
5. PFSense + Splunk - Security on the cheap - Parsing DHCP Server Logs

PFSense + Splunk - Security on the cheap - Parsing ARPWatch Logs

Continuing with the Splunk dashboards, let's add a panel for parsed ARPWatch logs

Sample ARPWatch Log Message
Apr 14 16:05:49 192.168.0.1 Apr 14 20:05:08 kernel: arp: 192.X.X.11 moved from 24:77:03:32:55:30 to 88:53:2e:50:9d:3f on dc0

This message shows that the MAC Address for IP 192.X.X.11 has changed. This is significant as it can help to detect ARP Spoofing


Our Search Filter:
host="pfsense_firewall" arp: | rex field=_raw "arp:\s(?<ip_address>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\smoved\sfrom\s(?<before_mac>[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2})\sto\s(?<after_mac>[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2}:[A-Fa-f0-9]{2})\son\s(?<interface>.*)" | stats count by ip_address, before_mac, after_mac, interface

Our Results


Being able to track changing MAC Addresses may help you identify missconfigured and or malicious hosts in your network.


----- Updated on January 11, 2020 -------
I received a log from a reader who was unable to extract fields from it seems a different log produced by PFSense. Here is that log:

"Jan 11 17:49:20 192.168.10.254 Jan 11 17:49:20 arpwatch: bogon 169.254.39.39 2c:fd:a1:3d:4b:dc"

I then duplicated this log to have a few entries:

"Dec 11 17:49:20 192.168.10.254 Jan 11 17:49:20 arpwatch: bogon 169.254.39.39 2c:fd:a1:3d:4b:dc
Jan 11 17:49:20 192.168.11.25 Jan 11 17:49:20 arpwatch: bogon 169.254.20.39 2c:fd:a1:3d:4b:dc
Mar 11 17:49:20 192.168.9.254 Jan 11 17:49:20 arpwatch: bogon 169.254.5.39 2c:fd:a1:3d:4b:dc
Jun 11 17:49:20 192.168.10.254 Jan 11 17:49:20 arpwatch: bogon 169.254.39.39 2c:fd:a1:3d:4b:dc
Jan 11 17:49:20 192.168.11.25 Jan 11 17:49:20 arpwatch: bogon 169.254.20.39 2c:fd:a1:3d:4b:dc

Jul 11 17:49:20 192.168.9.254 Jan 11 17:49:20 arpwatch: bogon 169.254.5.39 2c:fd:a1:3d:4b:dc"


Below is the new extraction:
"source="/opt/bro/logs/current/arpwatch.log" | rex field=_raw "(?<ip_address>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}).*bogon\s+(?<bogon_ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\s+(?<mac_address>.*)" | stats count by ip_address, bogon_ip, mac_address"

Here is the output from that filter:

See you in the next post where we parse DHCP Logs
In this series:
1. PFSense + Splunk - Security on the cheap
2. PFSense + Splunk - Security on the cheap - Parsing Firewall logs
3. PFSense + Splunk - Security on the cheap - Parsing ARPWatch Logs
4. PFSense + Splunk - Security on the cheap - Parsing Snort Logs
5. PFSense + Splunk - Security on the cheap - Parsing DHCP Server Logs

PFSense + Splunk - Security on the cheap - Parsing Firewall logs

Splunk allows you to build dashboards which can be the view you see as you enter Splunk.

The searches below should be plugged into your dashboards as a panel, giving you a quick environment overview.

Sample Firewall Log
May  1 19:43:35 pfsense_firewall May  1 23:43:25 filterlog: 78,16777216,,1000002761,eth0,match,pass,out,4,0x0,,63,55879,0,DF,6,tcp,60,10.0.0.2,10.0.0.3,52008,443,0,S,4088643738,,14600,,mss;sackOK;TS;nop;wscaleFrom the above we can see that the firewall logs are flagged via "filterlog:". Using this information we will build out the information to monitor for the firewalls.

First let's build a table that allows us to get a view of all information flow seen by the firewall

Our search filter:
host="pfsense-firewall" "filterlog:"  | rex field=_raw "filterlog:\s[0-9]*,[0-9]*,,[0-9]*,(?<interface>[0-9A-Za-z]*),(?<status>[A-Za-z]*),(?<pass_block>[A-Za-z]*),(?<in_out>[A-Za-z]*),[0-9]*,[0-9A-Za-z\s]*,[0-9]*,[0-9]*,[0-9]*,[0-9]*,[0-9A-Za-z]*,(?<protocol_number>[0-9]*),(?<protocol>[A-Za-z0-9]*),[0-9]*,(?<s_ip>[A-Za-z0-9\.\:]*),(?<d_ip>[A-Za-z0-9\.\:]*),(?<s_port>[0-9]*),(?<d_port>[0-9]*)"

The result of the above is shown below:


Now that we have the overview of the traffic, let's expand on our security monitoring by being a bit more focused. Let's look at the more active IPs

Our search filter:
host="pfsense_firewall" "filterlog:" ,match,pass, NOT *v6 | rex field=_raw "filterlog:\s[0-9]*,[0-9]*,,[0-9]*,(?<interface>[0-9A-Za-z]*),(?<status>[A-Za-z]*),(?<pass_block>[A-Za-z]*),(?<in_out>[A-Za-z]*),[0-9]*,[0-9A-Za-z\s]*,[0-9]*,[0-9]*,[0-9]*,[0-9]*,[0-9A-Za-z]*,(?<protocol_number>[0-9]*),(?<protocol>[A-Za-z0-9]*),[0-9]*,(?<s_ip>[A-Za-z0-9\.\:]*),(?<d_ip>[A-Za-z0-9\.\:]*),(?<s_port>[0-9]*),(?<d_port>[0-9]*)" | stats count by s_ip | sort count | reverse

Results of our search






















While monitoring successful IPs is important, monitoring dropped IPs is just as important. These dropped IPs can serve as an early warning system

Our search filter:
host="pfsense_firewall" "filterlog:" ,match,block, NOT *v6  | rex field=_raw "filterlog:\s[0-9]*,[0-9]*,,[0-9]*,(?<interface>[0-9A-Za-z]*),(?<status>[A-Za-z]*),(?<pass_block>[A-Za-z]*),(?<in_out>[A-Za-z]*),[0-9]*,[0-9A-Za-z\s]*,[0-9]*,[0-9]*,[0-9]*,[0-9]*,[0-9A-Za-z]*,(?<protocol_number>[0-9]*),(?<protocol>[A-Za-z0-9]*),[0-9]*,(?<s_ip>[A-Za-z0-9\.\:]*),(?<d_ip>[A-Za-z0-9\.\:]*),(?<s_port>[0-9]*),(?<d_port>[0-9]*)" | stats count by s_ip | sort count | reverse

Search Results:























Monitoring allowed ports
Monitoring the allowed ports is just as important as monitoring the blocked ports. The objective here is that you get an idea of what ports are allowed through your network. This information may help you to recognise a misconfigured firewall or even a host that is infected or behaving in a suspicious manner.

Our search filter:
host="pfsense_firewall" "filterlog:" ,match,pass, NOT *v6 | rex field=_raw "filterlog:\s[0-9]*,[0-9]*,,[0-9]*,(?<interface>[0-9A-Za-z]*),(?<status>[A-Za-z]*),(?<pass_block>[A-Za-z]*),(?<in_out>[A-Za-z]*),[0-9]*,[0-9A-Za-z\s]*,[0-9]*,[0-9]*,[0-9]*,[0-9]*,[0-9A-Za-z]*,(?<protocol_number>[0-9]*),(?<protocol>[A-Za-z0-9]*),[0-9]*,(?<s_ip>[A-Za-z0-9\.\:]*),(?<d_ip>[A-Za-z0-9\.\:]*),(?<s_port>[0-9]*),(?<d_port>[0-9]*)" | stats count by d_port | sort count | reverse

Search results:




monitoring blocked ports

Similarly to monitoring allowed ports, we also need to monitor blocked ports. This helps us to understand which hosts may be trying to communicate on ports which are not allowed on the network helping to add context to the environment.

Our search filter:
host="pfsense_firewall" "filterlog:" ,match,block, NOT *v6 | rex field=_raw "filterlog:\s[0-9]*,[0-9]*,,[0-9]*,(?<interface>[0-9A-Za-z]*),(?<status>[A-Za-z]*),(?<pass_block>[A-Za-z]*),(?<in_out>[A-Za-z]*),[0-9]*,[0-9A-Za-z\s]*,[0-9]*,[0-9]*,[0-9]*,[0-9]*,[0-9A-Za-z]*,(?<protocol_number>[0-9]*),(?<protocol>[A-Za-z0-9]*),[0-9]*,(?<s_ip>[A-Za-z0-9\.\:]*),(?<d_ip>[A-Za-z0-9\.\:]*),(?<s_port>[0-9]*),(?<d_port>[0-9]*)" | stats count by d_port | sort count | reverse

Search results:


The above should give us a very good idea about the hosts that are communicating through our firewall and how the traffic is distributed. This is extremely important as it helps to add context to your environment and where possible create a baseline.

Hope you enjoyed this post. See you in the post on parsing snort alert logs.
In this series:
1. PFSense + Splunk - Security on the cheap
2. PFSense + Splunk - Security on the cheap - Parsing Firewall logs
3. PFSense + Splunk - Security on the cheap - Parsing ARPWatch Logs
4. PFSense + Splunk - Security on the cheap - Parsing Snort Logs
5. PFSense + Splunk - Security on the cheap - Parsing DHCP Server Logs

PFSense + Splunk - Security on the cheap

PFSense + Splunk - Security on the cheap

PFSense is a wonderful piece of free software. Using the free Splunk along with PFSense can give you quite a effective way to start securing your environment without having to spend a dime.

In this post we will not look at configuring PFSense packages. However, we will look at configuring forwarding of the logs below to a remote Syslog server. In this case we will use Splunk to parse
1. Parsing Firewall logs
2. Parsing ARPWatch Logs
3. Parsing Snort Logs
4. Parsing DHCP Server Logs
     
To configure PFSense to forward logs we must do the following:
    1.    From the "Diagnostics" tab, select "System Activity"
    2.    In the "Systems Activity" window, ensure the following are checked:
        (i)        Show log entries in reverse order (newest entries on top)
        (ii)    Log packets matched from the default block rules put in the ruleset
        (iii)    Log packets matched from the default pass rules put in the ruleset
        (iv)     Log packets blocked by 'Block Bogon Networks' rules
        (v)         Log packets blocked by 'Block Private Networks' rules
        (vi)     Log errors from the web server process.
      
    3. Optional - if you don't wish to write the logs to the local firewall ensure the following is checked  
        (i)     Disable writing log files to the local disk
      
    4,    From the "Source Address" drop down select "LAN"
    5.    Select your "IP Protocol" - I'm sure this would be IPv4
    6.     For "Enable Remote Logging", ensure " Send log messages to remote syslog server" is checked
    7.  For "Remote Syslog Servers", enter the IP address of your Splunk Instance
    8.    For "Remote Syslog Contents", ensure "Everything" is checked - unless you wish to be specific
 
Below shows a snapshot of what we should be doing.

Above image shows part of the configuration needed for PFSense to send its logs to Splunk

Next post we will look at parsing this data out in Splunk
In this series:
1. PFSense + Splunk - Security on the cheap
2. PFSense + Splunk - Security on the cheap - Parsing Firewall logs
3. PFSense + Splunk - Security on the cheap - Parsing ARPWatch Logs
4. PFSense + Splunk - Security on the cheap - Parsing Snort Logs
5. PFSense + Splunk - Security on the cheap - Parsing DHCP Server Logs

Privacy vs Security In The Age Of PRISM

Introduction

As we continue to march forward with advances in technology, technology continues to cause friction between privacy and security. In addition, as technology becomes more easily available and accessible, it also becomes more pervasive. This pervasiveness allow governments to find new and creative way to police its citizens by snooping on their communications. In addition, governments have taken steps to enact laws which gives them seemingly unfettered access to their citizens communications and hence their data. One such program which was implemented as a result of these new laws in the United States (US), is PRISM. These new policing measures are currently the primary contributing factors in the debate of security vs privacy.

PRISM Background

PRISM is an internal US Government computer system which was created in 2008 by the US Congress. It’s primary purpose is to facilitate the authorized collection of foreign intelligence information via electronic sources and through various electronic communication service providers (Director of National Intelligence, 2013).  This program has resulted in numerous lawsuits which challenges not only its authenticity but also its infringement on the privacy of US citizens. According to (Director of National Intelligence, 2013), the objective of this program is to acquire foreign intelligence information on targets located outside of the US. However, the PRISM program through top secret court orders, has compelled companies like Verizon to turn over millions of US customers data (Greenwald & MacAskill, 2013). In addition, the collection of intelligence – be it accidental or deliberate – such as email, voice, text, video chats, etc., from a number of US citizens via companies such as Microsoft, Yahoo, Google, Apple, etc., contributes significantly to debate that PRISM encroaches on the privacy of US citizens (Gellman & Lindeman, 2013). The biggest concern and threat to privacy is the National Security Agency’s (NSA) ability to obtain information without having to request them from the service provider or without the need for a court order (Greenwald & MacAskill, 2013) along with the Government’s threat to apply significant financial penalties to organization that refuses to cooperate in providing data about their users, as was done to Yahoo (Rusche, 2014).

The Need For Security

            Providing security for its citizens is one of the top priority for any government and the US Government is no different. The US Government through institutions such as the Department of Homeland Security (DHS) strive to protect the homeland and ensure it is safe, secure and resilient against terrorist and other hazards (dhs.gov, 2012). In addition organization’s such as the National Security Agency (NSA) confronts the challenges of preventing adversaries from gaining access to sensitive or classified national security information (nsa.gov, 2011). The world as we know it at present is a very dangerous place. On September 11, 2011, terrorist executed the worst ever attack in US history, flying 2 planes into the World Trade Center Buildings, causing the deaths of 2,977 people  (cnn.com, 2015). On April 15, 2013 two brothers, Dzhokhar Tsarnaev and Tamerlan Tsarnaev detonated 2 bombs at the Boston Marathon, killing 3 and wounding 260 people (History.com Staff, 2014). These two examples support the case for some of the measures governments may need to put in place to prevent these types of activities. Governments should not always be in a reactive mode but instead should be more proactive. As a result the need for programs such as PRISM becomes more relevant providing they do not encroach on the privacy of citizens. These programs allow governments through institutions such as DHS and NSA to be proactive by collecting intelligence which gives the relevant insights allowing it to make decisions which may ultimately prevent attacks such as the ones above.

The Need For Privacy

            The development and advancement of technology makes the argument for privacy much greater. As stated by (Brenner, 2010) “Ways may . . . be developed by which the government, without removing papers from secret drawers, can reproduce them in court, and by which it will be enabled to expose . . . the most intimate occurrences of the home.” The aforementioned, shows that unless governments are kept in check, our privacy may be so eroded that we no longer have any left. It is one thing to allow and or give the government through agencies such as DHS and NSA the capabilities to protect us from harm which may be perpetuated against us. However, it is also our responsibility to ensure that the government does not exploit those privileges with the ultimate objective of eroding our right to privacy. We should all care about privacy even though privacy is not necessarily secrecy (Doctorow, 2013). If the government through its agencies like DHS and or NSA were to retrieve information which suggest you did something wrong, then these agencies may view everything else you do through the lens of this data (Doctorow, 2013). If our privacy is taken away, then all persons will become suspect. However, some persons will be more suspect than others (Mery, 2005).  

As a people, if we need proof as to why we should take our privacy seriously, the case of David Mery should serve as an absolute wake up call. David Mery was arrested and charged under the UK Terrorism Act for suspicious behavior and public nuisance.  This all stemmed from his behavior being deemed suspicious by police after direct observation of him from watching the CCTV system while he was in the London Subway. The charges were ultimately dropped. However, even though the charges were dropped, the police were still entitled to hold on to Mery’s fingerprints, DNA, anything gathered during the investigations, photographs, interviewing tapes, etc. (Mery, 2005) The biggest concern with this case is even though Mery was considered innocent in the eyes of the law, he is also still guilty as a result of the law, as he cannot now get his file wiped.

Legal Challenges To PRISM

            Legal means have always been used to challenge the legality of laws and or programs which have been implemented by Governments. PRISM has had its fair share of lawsuits which challenges various aspects of the program. However, some of these lawsuits have been successful while others have been unsuccessful. Yahoo’s unsuccessful bid to challenge the government and the laws which supports PRISM on the grounds that it was unconstitutional and overboard (Rusche, 2014) is evidence that it can be difficult to win cases against the government. Once Yahoo lost their case, the government added even more pressure to obtain the requested data by threatening to fine Yahoo $250,000 per day with that amount doubling weekly. Similarly to Yahoo, the American Civil Liberties Union (ACLU) has filed a law suit against the PRISM program stating that it is unconstitutional (aclu.org, 2013). These lawsuits may end up providing greater insight into the operation of the PRISM program. However, if the government continues to threaten companies that refuses to comply, then the program will always be viewed suspiciously.

Conclusion

In a debate between security vs privacy, my choice will always be privacy. There has been many instances in which I have seen and can clearly understand how and why some persons can choose to believe any and everything that is produced by the computer and or devices used for computing. While it is one thing for data to be retrieved about us, when that data is considered to be retrieved without our permission and encroaches on my privacy that should be of greater concern. More importantly, how that data is used should be our biggest fear. The problem with using this data is not only its usage but its ultimate interpretation by the personnel entrusted with it. Therefore it is our responsibility to ensure that we take all measures available to guard our privacy and in the process reduce the amount of information governments through their agencies such as DHS and NSA can obtain from and about us.

It is clearly understood and expected that the government will need to collect information to proactively protect its citizens. In collecting this data, the government should be able to identify when it may be going beyond its reach and thus encroaching on our privacy or breaching our constitutional rights. Because governments seldom considers our privacy first when focusing on securing its citizens, it is the citizens’ responsibility to keep the government actions in check. Unless this is done, the government will continue marching forward enacting laws which encroaches on our privacy and after a while we may be at a stage at which all our privacy has been eroded. Ultimately, as it was asked by (Mery, 2005), “Isn't a state that keeps files on innocent persons a police state?”

References

aclu.org. (2013, June 11). ACLU Files Lawsuit Challenging Constitutionality of NSA Phone Spying Program. Retrieved from aclu.org: https://www.aclu.org/news/aclu-files-lawsuit-challenging-constitutionality-nsa-phone-spying-program?redirect=national-security/aclu-files-lawsuit-challenging-constitutionality-nsa-phone-spying-program

Brenner, S. (2010). Cybercrime, Criminal Threats from Cyberspace. Santa Barbara, California: Praeger.

cnn.com. (2015, March 27). September 11th Fast Facts. Retrieved from cnn.com: http://www.cnn.com/2013/07/27/us/september-11-anniversary-fast-facts/

dhs.gov. (2012, December 17). Our Mission. Retrieved from dhs.gov: http://www.dhs.gov/our-mission

Director of National Intelligence. (2013). Facts on the Collection of Intelligence Pursuant to Section 702 of the Foreign Intelligence Surveillance Act. Washington, DC 20511.

Doctorow, C. (2013, June 14). The NSA's Prism: why we should care . Retrieved from theguardian.com: http://www.theguardian.com/technology/blog/2013/jun/14/nsa-prism

Gellman, B., & Lindeman, T. (2013, June 29). Inner workings of a top-secret spy program. Retrieved from http://apps.washingtonpost.com: http://apps.washingtonpost.com/g/page/national/inner-workings-of-a-top-secret-spy-program/282/

Greenwald, G., & MacAskill, E. (2013, June 7). NSA Prism program taps in to user data of Apple, Google and others. Retrieved from theguardian.com: http://www.theguardian.com/world/2013/jun/06/us-tech-giants-nsa-data

History.com Staff. (2014). Boston Marathon Bombings. Retrieved from history.com: http://www.history.com/topics/boston-marathon-bombings

Mery, D. (2005, September 22). Suspicious behaviour on the tube . Retrieved from theguardian.com: http://www.theguardian.com/world/2005/sep/22/terrorism.july7

nsa.gov. (2011, April 15). Mission. Retrieved from nva.gov: https://www.nsa.gov/about/mission/index.shtml

Rusche, D. (2014, September 12). Yahoo $250,000 daily fine over NSA data refusal was set to double 'every week' . Retrieved from theguardian.com: http://www.theguardian.com/world/2014/sep/11/yahoo-nsa-lawsuit-documents-fine-user-data-refusal

theusconstitution.org. (n.d.). Current Cases. Retrieved from theusconstitution.org: http://theusconstitution.org/cases/current