BigIP/IQ Security Compliance Scanner
Hello All, I would like to initiate a discussion about a personal project I am developing. The following description of the project's goal will be an overview rather than a low-level description of how it will function. The project centers on a tool (desktop application/web app) that will allow F5 BigIP/IQ administrators/engineers to upload XML/JSON documents. The XML/JSON will contain a specific schema for security settings that the application parses and translates into iControl REST API calls or TMSH commands via SSH to verify if the BigIP/IQ server is configured with a particular setting. Below are some examples to help demonstrate the overall concept. Example: User uploads XML document that contains the following security settings <?xml version="1.0" encoding="UTF-8"?> <Settings> <OnDemandCertAuth> <VerifyText>Run the below command in TMSH</VerifyText> <Action>tmsh modify sys httpd auth-pam-validate-ip on</Action> <Action>tmsh save sys config</Action> </OnDemandCertAuth> </Settings> Now that the doc is uploaded, the app parses the XML for the "<Action>" element, then creates the related tmsh show command or potential iControl REST API call to verify if httpd is validating IPs on standard auth to the GUI, in this example. Depending on the data returned from TMSH or the API, the application would then present the user with a table in the GUI that shows the checks that passed and failed. Then they could remediate the system to have the correct security setting for compliance. Lastly, I'd like to provide a bit more background on the inspiration for this tool. I work a lot in the federal space, where we have to make sure our F5 products meet a baseline security standard. Currently, there are no tools that automate this like there are for Windows products, etc. If you have ever used the SCAP tool for DISA STIGs, then you'll understand the overall goal of this project. Thank you for taking the time to review my post to the community. I'd love to hear your feedback!Maintaining BIG-IP's Golden Compliance Configuration in Financial Services
For financial services organizations, demonstrating compliance is not just about satisfying auditors; it's about safeguarding trust in every transaction. By applying the strategies outlined in this article, teams can minimize configuration drift, maintain golden state readiness, and respond effectively to audits—even in high-pressure environments.
Inspec/Rspec Tests and Compliance BigIp f5
Anyone doing any work at the moment with inspec tests for f5's? Started using inspec and pretty quick to write tests in a ruby container, but seems no native stuff for f5, other than rolling my own with the rest api? *tried searching already* - maybe there are other resources someone can help with? Thanks in advance.
Making WAF Simple: Introducing the OWASP Compliance Dashboard
Whether you are a beginner or an expert, there is a truth that I want to let you in on; building and maintaining Web Application Firewall (WAF) security policies can be challenging. How much security do you really need? Is your configuration too much or too little? Have you created an operational nightmare? Many well-intentioned administrators will initially enable every available feature, thinking that it is providing additional security to the application, when in truth, it is hindering it. How, you may ask? False positives and noise. The more noise and false positives, the harder it becomes to find the real attacks and the increased likelihood that you begin disabling features that ARE providing essential security for your applications. So… less is better then? That isn't the answer either, what good are our security solutions if they aren't protecting against anything? The key to success and what we will look at further in this article, is implementing best practice controls that are both measurable and manageable for your organization. The OWASP Application Security Top 10 is a well-respected list of the ten most prevalent and dangerous application layer attacks that you almost certainly should protect your applications from. By first focusing your security controls on the items in the OWASP Top 10, you are improving the manageability of your security solution and getting the most "bang for your buck". Now, the challenge is, how do you take such a list and build real security protections for your applications? Introducing the OWASP Compliance Dashboard Protecting your applications against the OWASP Top 10 is not a new thing, in fact, many organizations have been taking this approach for quite some time. The challenge is that most implementations that claim to "protect" against the OWASP Top 10 rely solely on signature-based protections for only a small subset of the list and provide zero insight into your compliance status. The OWASP Compliance Dashboard introduced in version 15.0 on BIG-IP Advanced WAF reinvents this idea by providing a holistic and interactive dashboard that clearly measures your compliancy against the OWASP Application Security Top 10. The Top 10 is then broken down into specific security protections including both positive and negative security controls that can be enabled, disabled, or ignored directly on the dashboard. We realize that a WAF policy alone may not provide complete protection across the OWASP Top 10, this is why the dashboard also includes the ability to review and track the compliancy of best practices outside the scope of a WAF alone, such as whether the application is subject to routine patching or vulnerability scanning. To illustrate this, let’s assume I have created a brand new WAF policy using the Rapid Deployment policy template and accepted all default settings, what compliance score do you think this policy might have? Let's take a look. Interesting. The policy is 0/10 compliant and only A2 Broken Authentication and A3 Sensitive Data Exposure have partial compliance. Why is that? The Rapid Deployment template should include some protections by default, shouldn't it? Expanding A1 Injection, we see a list of protections required in order to be marked as compliant. Hovering over the list of attack signatures, we see that each category of signature is in 'Staging' mode, aha! Signatures in staging mode are not enforced and therefore cannot block traffic. Until the signature set is in enforced, we do not mark that protection as compliant. For those of you who have mistakenly left entities such as Signatures in staging for longer than desired, this is also a GREAT way to quickly find them. I also told you we could also interact with the dashboard to influence the compliancy score, lets demonstrate that. Each item can be enforced DIRECTLY on the dashboard by selecting the "Enforce" checkmark on the right. No need to go into multiple menus, you can enforce all these security settings on a single page and preview the compliance status immediately. If you are happy with your selection, click on "Review & Update" to perform a final review of what the dashboard will be configuring on your behalf before you can click on "Save & Apply Policy". Note: Enforcing signatures before a period of staging may not be a good idea depending on your environment. Staging provides a period to assess signature matches in order to eliminate false positives. Enforcing these signatures too quickly could result in the denying of legitimate traffic. Let's review the compliancy of our policy now with these changes applied. As you can see, A1 Injection is now 100% compliant and other categories have also had their score updated as a result of enforcing these signatures. The reason for this is because there is overlap in the security controls applied across these other categories. Not all security controls can be fully implemented directly via the dashboard, and as mentioned previously, not all security controls are signature-based. A6 Cross-Site Scripting was recalculated as 50% complaint with the signatures we enforced previously so let's take a look at what else it required for full compliancy. The options available to us are to IGNORE the requirement, meaning we will be granted full compliancy for that item without implementing any protection, or we can manually configure the protection referenced. We may want to ignore a protection if it is not applicable to the application or if it is not in scope for your deployment. Be mindful that ignoring an item means you are potentially misrepresenting the score of your policy, be very certain that the protection you are ignoring is in fact not applicable before doing so. I've selected to ignore the requirement for "Disallowed Meta Characters in Parameters" and my policy is now 100% compliance for A7 Cross-Site Scripting (XSS). Lastly, we will look at items within the dashboard that fall outside the scope of WAF protections. Under A9 Using Components with Known Vulnerabilities, we are presented with a series of best practices such as “Application and system hardening”, “Application and system patching” and “Vulnerability scanner integration”. Using the dashboard, you can click on the checkmark to the right for "Requirement fulfilled" to indicate that your organization implements these best practices. By doing so, the OWASP Compliance score updates, providing you with real-time visibility into the compliancy for your application. Conclusion The OWASP Compliance Dashboard on BIG-IP Advanced WAF is a perfect fit for the security administrator looking to fine-tune and measure either existing or new WAF policies against the OWASP App Security Top 10. The OWASP Compliance Dashboard not only tracks WAF-specific security protections but also includes general best practices, allowing you to use the dashboard as your one-stop-shop to measure the compliancy for ALL your applications. For many applications, protection against the OWASP Top 10 may be enough, as it provides you with best practices to follow without having to worry about which features to implement and where. Note: Keep in mind that some applications may require additional controls beyond the protections included in the OWASP Top 10 list. For teams heavily embracing automation and CI/CD pipelines, logging into a GUI to perform changes likely does not sound appealing. In that case, I suggest reading more about our Declarative Advanced WAF policy framework which can be used to represent the WAF policies in any CI/CD pipeline. Combine this with the OWASP Compliance Dashboard for an at-a-glance assessment of your policy and you have the best of both worlds. If you're not already using the OWASP Compliance Dashboard, what are you waiting for? Look out for Bill Brazill, Victor Granic and myself (Kyle McKay) on June 10th at F5 Agility 2020 where we will be presenting and facilitating a class called "Protecting against the OWASP Top 10". In this class, we will be showcasing the OWASP Compliance Dashboard on BIG-IP Advanced WAF further and providing ample hands-on time fine-tuning and measuring WAF policies for OWASP Compliance. Hope to see you there! To learn more, visit the links below. Links OWASP Compliance Dashboard: https://support.f5.com/csp/article/K52596282 OWASP Application Security Top 10: https://owasp.org/www-project-top-ten/ Agility 2020: https://www.f5.com/agility/attendNIST SP 800-53r4 iApp template
Problem this snippet solves: This iApp template helps you configure BIG-IP to support security controls consonant with NIST Special Publication 800-53r4. This iApp focuses on management of the BIG-IP itself rather than control of application traffic through the BIG-IP. For more details on this iApp and how it supports NIST Special Publication 800-53r4, enable the Inline Help within the template. The Help tab in the GUI contains additional information. The associated deployment guide is now available at http://www.f5.com/pdf/deployment-guides/nist-sp-800-53-r4-dg.pdf Fully supported version v1.0.0 - Supported release Released the fully supported version of the NIST iApp on 02-08-17. There were no additional changes to the iApp template over RC-6, however the iApp now supports BIG-IP versions 11.5.3 - 12.1.2. See https://support.f5.com/csp/article/K09154349 for instructions on downloading, importing and using the iApp. Release Candidate versions v1.0.1rc3 and rc4 RC3 was released on downloads.f5.com with a single fix (corrected an issue where the iApp would incorrectly detect Appliance Mode). As a part of this fix, the iApp would not load on BIG-IP systems that had a previous version of the NIST iApp. F5 released RC4 on DevCentral with a fix for this issue, and now the iApp loads properly on all devices. This version also contains a fix for multi-line banners and a fix for SNMP so the iApp catches any form of 127.0.0.0 and maps it. Released 1.0.1rc4 of the NIST iApp on 06-18-2018. v1.0.1rc1 Released 1.0.1rc1 of the NIST iApp on 08-18-2017. This version corrects an issue that would cause iApp Failure when configuring custom ports for self IP port lockdown v1.0.0rc6 Released RC-6 of the NIST iApp on 12-12-2016. In RC-6, all customer secrets/passwords in the iApp template are now securely stored. Previously, although secrets were stored in Secure Vault for use, some may have been stored in cleartext in the iApp reconfiguration data.* Added support for BIG-IP versions 12.1 and 12.1.1. Made error messages produced by the template easier to understand. If using RADIUS authentication, you are now limited a maximum of 10 servers. Previously there was no limit. The source-IP option on additional syslog servers is honored in this version. Previously this field was ignored. v1.0.0rc5 Released RC-5 of the NIST iApp on 12-16-2015. RC-5 adds a new question to the iApp template if you specified LDAP as your authentication method, asking if the directory user objects include group-membership attributes (like memberOf). Adds All as an option for remote-role partition access Other minor bug fixes. v1.0.0rc4 Released RC-4 of the NIST iApp on 12-02-2015. RC-4 adds support for BIG-IP v11.5.3. The main difference is the "Fraud Protection Manager" role was not available in 11.5.3, and only v11.6 and later.* Added the iRule Manager role that was missing in previous versions of the iApp. Clarified the answers and inline help for the MCPD audit log section. v1.0.0rc3 Released RC-3 of the NIST iApp on 11-12-2015. RC-3 contains mostly clarifications to the iApp presentation, including question/answer text and the inline help. Added warning messages where applicable. For the Management Access and SNMP Access IP addresses sections, removed the option to not allow any IP addresses, as this could cause issues, such as users inadvertently locking themselves out of the system. v1.0.0rc2 Released RC-2 of the NIST iApp on 10-30-2015. RC-2 corrects an issue where the option to revert to the pre-iApp configuration was not working properly.* Enhanced the management of self-IP access policies. Changes are now saved as the default for use with new self-IP objects as well as applied to existing self IP objects. Code : 88573What To Expect In 2017: Security And Government Regulations
The government and cloud security's relationship is surprisingly hands off. Current regulations already extend their umbrellas over our data in flight and rest regardless who's IaaS/SaaS you're using. For us traditional enterprise administrators, the regulations are established and and we follow them to because we're all perfect and deserve raises. But when it comes to "the cloud" we've introduced developers and application admins releasing services to the general public with great hates; sometimes without the checks and balances needed for compliance. The results are mixed. Increasingly popular scan-all-the-things method of finding vulnerable systems are weeding out quite a few unprotected cloud-connected data sets. Even the smallest vendor needs to validate their compliance requirements and implement them at the same pace they're implementing publicly available applications. HIPAA The Health Insurance Portability and Accountability Act of 1996 (HIPAA) completed enforcement of security policies on personal health care information (PHI) in 2006. HIPPA includes polices related from control and auditing to intrusion prevention and alerting, data validation, authentication practices, and risk analysis and remediation plans (and a host of other things we admins don't care as much about). We know we're getting compliance wrong because as of January 31st of 2017, the Office of Civil Rights has received since 2003 over 148,292 complaints of violation (complaint != violation). 2017 will see more and more companies deploying cloud services that will start to gray the area between basic PII and PHI. Think Strava recording your epic bike ride or your Garmin tracking your last run... all store data relevant to you and how it relates to your physical condition. What's more interesting to investigate is what are your rights to your last bike ride's information? Can it be sold with only basic de-identification? The boundaries between PHI and PII are blurring from our desires to connect our selves so expect a lot of angry people when an insurance provider is found denying a claim based off "acquired" Fitbit data. SOX Thanks ENRON (and Tyco/WorldCom) for getting the Sarbanes-Oxley (SOX) Act of 2020 thrust onto all publicly traded companies. SOX regulates financial practices and corporate governance divided into 11 titles most of which are related to enforcing basic ethics we apparently take for granted. Section 802 is a whole different InfoSec ball game regulating data retention, classification, and records keeping to ensure the shredder doesn't get used too much. And the cloud has made complying with 802's requirements much. Data governance tools, DLP, and enhanced record keeping tools are being introduced into all of our favorite cloud apps from Office 365 to Slack. It's assumed SOX will play a requirement for many cloud applications so the needed technologies should exist out of the gate. FIPS The Federal Information Processing Standards (FIPS) standardizes government use in computer systems by non-military agencies and contractors. Most people are familiar with FIPS 140-2: Security Requirements for Cryptographic Modules because it's so cool and interesting. FIPS 200: Minimum Security Requirements for Federal Information and Information Systems will be more prevalent as federal providers are encouraged/forced to use authorized cloud resources to migrate off existing internal government IT disasters and deprecating systems. The massive failure of the Office of Personnel Management and the years-blame game still underway is making private could resources more attractive to existing government entities. FIPS 200 will play a vital role for those Iaas/Saas providers to ensure they can receive those federal dollars. It's going to happen, it's already happening; maybe we can stop being embarassed by the federal fire hose of data breaches. FERPA The Family Educational Rights and Privacy Act (FERPA) is not well know to us outside of educational service branches but your child's data is just as important as your PHI information. Specifically targeted at protecting student records, FERPA puts the students data into the governing parent/guardians control and approval. However, the infrastructure responsible for data handling are sometimes the same systems Ferris Bueller hacked into and changed his absentee violations. Like FIPS, educational providers are migrating to the cloud in lieu of massive IT budget shortfalls to upgrading existing infrastructure. Cloud providers are few and far between to slap on a FERPA compliance sticker. Given the coverage provided by other regulations, there shouldn't be too much adjusting for the cloud providers new to the educational market. EU-US Privacy Shield You want to do business with any European Union corporation? You want to build an office in any of those countries? Unless you want to spend the next 100 years working with different data privacy laws enacted by disparate governments, join the EU-US Privacy Shield program. When an org joins the EUUSPS they'll self-certify with Department of Commerce and commit to the existing and future framework requirements. This has massive impact to the larger providers and services living in those geo-located clouds. You essentially become an international data steward who agrees to abide by a larger protection clause than one defined for U.S citizens. It's a good thing. That's what they tell me. EU NIS Directive The Directive on security of network and information systems (EU NIS Directive) was enacted July 6th, 2016 to provide a minimum compliance for data security against cyber-bad things for any country operating in or applying for European Union membership. This was to create a strong "weakest link" for countries with poor infrastructure policies and practices from being penetrated by nation states close to those countries. This directive was created in response to growing shady nation state cyber practices, worrying existing western block EU members. 2017 will test the strength of these policies and their violation penalties. None of this should be of any concern to existing cloud providers as they're operating in developed InfoSec countries. For the increasingly talented developer pool in the eastern EU, this still may be new and a potential stumbling block. Similar to new developers in the U.S. screwing up their PCI-DSS compliance, language barriers and InfoSec may be stumbling blocks exposing private EU citizen data. This is just a summary of some of the regulations that will see more-than-normal impact to the next generation of IaaS/Saas providers and their clients in the coming months. It's apparent from the too-numerous to name breaches, that our data isn't secure and the more we utilize the cloud in our personal lives, the more we're willing to expose. For enterprises though, the alarm is not as needed as we're already seasoned to regulations and how to protect our data. Balancing the agile world of DevOps does threaten stable security practices but your InfoSec team should make you well aware before the fed comes-a-knockin.Complying with PCI DSS–Part 3: Maintain a Vulnerability Management Program
According to the PCI SSC, there are 12 PCI DSS requirements that satisfy a variety of security goals. Areas of focus include building and maintaining a secure network, protecting stored cardholder data, maintaining a vulnerability management program, implementing strong access control measures, regularly monitoring and testing networks, and maintaining information security policies. The essential framework of the PCI DSS encompasses assessment, remediation, and reporting. We’re exploring how F5 can help organizations gain or maintain compliance and today is Maintain a Vulnerability Management Program which includes PCI Requirements 5 and 6. To read Part 1, click: Complying with PCI DSS–Part 1: Build and Maintain a Secure Network and Part 2: Complying with PCI DSS–Part 2: Protect Cardholder Data Requirement 5: Use and regularly update antivirus software or programs. PCI DSS Quick Reference Guide description: Vulnerability management is the process of systematically and continuously finding weaknesses in an entity’s payment card infrastructure system. This includes security procedures, system design, implementation, or internal controls that could be exploited to violate system security policy. Solution: With BIG-IP APM and BIG-IP Edge Gateway, F5 provides the ability to scan any remote device or internal system to ensure that an updated antivirus package is running prior to permitting a connection to the network. Once connections are made, BIG-IP APM and BIG-IP Edge Gateway continually monitor the user connections for a vulnerable state change, and if one is detected, can quarantine the user on the fly into a safe, secure, and isolated network. Remediation services can include a URL redirect to an antivirus update server. For application servers in the data center, BIG-IP products can communicate with existing network security and monitoring tools. If an application server is found to be vulnerable or compromised, that device can be automatically quarantined or removed from the service pool. With BIG-IP ASM, file uploads can be extracted from requests and transferred over iCAP to a central antivirus (AV) scanner. If a file infection is detected, BIG-IP ASM will drop that request, making sure the file doesn’t reach the web server. Requirement 6: Develop and maintain secure systems and applications. PCI DSS Quick Reference Guide description: Security vulnerabilities in systems and applications may allow criminals to access PAN and other cardholder data. Many of these vulnerabilities are eliminated by installing vendor-provided security patches, which perform a quick-repair job for a specific piece of programming code. All critical systems must have the most recently released software patches to prevent exploitation. Entities should apply patches to less-critical systems as soon as possible, based on a risk-based vulnerability management program. Secure coding practices for developing applications, change control procedures, and other secure software development practices should always be followed. Solution: Requirements 6.1 through 6.5 deal with secure coding and application development; risk analysis, assessment, and mitigation; patching; and change control. Requirement 6.6 states: “Ensure all public-facing web applications are protected against known attacks, either by performing code vulnerability reviews at least annually or by installing a web application firewall in front of public-facing web applications.” This requirement can be easily met with BIG-IP ASM, which is a leading web application firewall (WAF) offering protection for vulnerable web applications. Using both a positive security model for dynamic application protection and a strong, signature-based negative security model, BIG-IP ASM provides application-layer protection against both targeted and generalized application attacks. It also protects against the Open Web Application Security Project (OWASP) Top Ten vulnerabilities and threats on the Web Application Security Consortium’s (WASC) Threat Classification lists. To assess a web application’s vulnerability, most organizations turn to a vulnerability scanner. The scanning schedule might depend on a change in control, as when an application is initially being deployed, or other triggers such as a quarterly report. The vulnerability scanner scours the web application, and in some cases actually attempts potential attacks, to generate a report indicating all possible vulnerabilities. This gives the administrator managing the web security devices a clear view of all exposed areas and potential threats to the website. Such a report is a moment-in time assessment and might not result in full application coverage, but should give administrators a clear picture of their web application security posture. It includes information about coding errors, weak authentication mechanisms, fields or parameters that query the database directly, or other vulnerabilities that provide unauthorized access to information, sensitive or not. Otherwise, many of these vulnerabilities would need to be manually re-coded or manually added to the WAF policy—both expensive undertakings. Simply having the vulnerability report, while beneficial, doesn’t make a web application secure. The real value of the report lies in how it enables an organization to determine the risk level and how best to mitigate the risk. Since recoding an application is expensive and time-consuming and may generate even more errors, many organizations deploy a WAF like BIG-IP ASM. A WAF enables an organization to protect its web applications by virtually patching the open vulnerabilities until developers have an opportunity to properly close the hole. Often, organizations use the vulnerability scanner report to either tighten or initially generate a WAF policy. While finding vulnerabilities helps organizations understand their exposure, they must also have the ability to quickly mitigate those vulnerabilities to greatly reduce the risk of application exploits. The longer an application remains vulnerable, the more likely it is to be compromised. For cloud deployments, BIG-IP ASM Virtual Edition (VE) delivers the same functionality as the physical edition and helps companies maintain compliance, including compliance with PCI DSS, when they deploy applications in the cloud. If an application vulnerability is discovered, BIG-IP ASM VE can quickly be deployed in a cloud environment, enabling organizations to immediately patch vulnerabilities virtually until the development team can permanently fix the application. Additionally, organizations are often unable to fix applications developed by third parties, and this lack of control prevents many of them from considering cloud deployments. But with BIG-IP ASM VE, organizations have full control over securing their cloud infrastructure. BIG-IP ASM version 11.1 includes integration with IBM Rational AppScan, Cenzic Hailstorm, QualysGuard WAS, and WhiteHat Sentinel, making BIG-IP ASM the most advanced vulnerability assessment and application protection on the market. In addition, administrators can better create and enforce policies with information about attack patterns from a grouping of violations or otherwise correlated incidents. In this way, BIG-IP ASM protects the applications between scanning and patching cycles and against zero-day attacks that signature-based scanners won’t find. Both are critical in creating a secure Application Delivery Network. BIG-IP ASM also makes it easy to understand where organizations stand relative to PCI DSS compliance. With the BIG-IP ASM PCI Compliance Report, organizations can quickly see each security measure required to comply with PCI DSS 2.0 and understand which measures are or are not relevant to BIG-IP ASM functions. For relevant security measures, the report indicates whether the organization’s BIG-IP ASM appliance complies with PCI DSS 2.0. For security measures that are not relevant to BIG-IP ASM, the report explains what action to take to achieve PCI DSS 2.0 compliance. BIG-IP ASM PCI Compliance Report Finally, with the unique F5 iHealth system, organizations can analyze the configuration of their BIG-IP products to identify any critical patches or security updates that may be necessary. Next: Implement Strong Access Control Measures psCloudFucius Wonders: Can Cloud, Confidentiality and The Constitution Coexist?
This question has been puzzling a few folks of late, not just CloudFucius. The Judicial/legal side of the internet seems to have gotten some attention lately even though courts have been trying to make sense and catch up with technology for some time, probably since the Electronic Communications Privacy Act of 1986. There are many issues involved here but a couple stand out for CloudFucius. First, there is the ‘Privacy vs. Convenience’ dilemma. Many love and often need the GPS Navigators whether it be a permanent unit in the vehicle or right from our handheld device to get where we need to go. These services are most beneficial when searching for a destination but it is also a ‘tracking bug’ in that, it records every movement we make. This has certainly been beneficial in many industries like trucking, delivery, automotive, retail and many others, even with some legal issues. It has helped locate people during emergencies and disasters. It has also helped in geo-tagging photographs. But, we do give up a lot of privacy, secrecy and confidentiality when using many of the technologies designed to make our lives ‘easier.’ Americans have a rather tortured relationship with privacy. They often say one thing ("Privacy is important to me") but do another ("Sure, thanks for the coupon, here's my Social Security Number") noted Lee Rainie, head of the Pew Internet and American Life Project. From: The Constitutional issues of cloud computing You might not want anyone knowing where you are going but by simply using a navigation system to get to your undisclosed location, someone can track you down. Often, you don’t even need to be in navigation mode to be tracked – just having GPS enabled can leave breadcrumbs. Don’t forget, even the most miniscule trips to the gas station can still contain valuable data….to someone. How do you know if your milk runs to the 7-Eleven aren’t being gathered and analyzed? At the same, where is that data stored, who has access and how is it being used? I use GPS when I need it and I’m not suggesting dumping it, just wondering. Found a story where Mobile Coupons are being offered to your phone. Depending on your GPS location, they can send you a coupon for a nearby merchant along with this one about Location-Based strategies. Second, is the Fourth Amendment in the digital age. In the United States, the 4th Amendment protects against unreasonable searches and seizures. Law enforcement needs to convince a judge that a serious crime has/is occurring to obtain a warrant prior to taking evidence from a physical location, like your home. It focuses on physical possessions and space. For instance, if you are committing crimes, you can place your devious plans in a safe hidden in your bedroom and law enforcement needs to present a search warrant before searching your home for such documents. But what happens if you decide to store your ‘Get rich quick scheme’ planning document in the cloud? Are you still protected? Can you expect certain procedures to be followed before that document is accessed? The Computer Crime & Intellectual Property Section of the US Dept of Justice site states: To determine whether an individual has a reasonable expectation of privacy in information stored in a computer, it helps to treat the computer like a closed container such as a briefcase or file cabinet. The Fourth Amendment generally prohibits law enforcement from accessing and viewing information stored in a computer if it would be prohibited from opening a closed container and examining its contents in the same situation….Although courts have generally agreed that electronic storage devices can be analogized to closed containers, they have reached differing conclusions about whether a computer or other storage device should be classified as a single closed container or whether each individual file stored within a computer or storage device should be treated as a separate closed container. But, you might lose that Fourth Amendment right when you give control to a third party, such as a cloud provider. Imagine you wrote a play about terrorism and used a cloud service to store your document. Maybe there were some ‘surveillance’ keywords or triggers used as character lines. Maybe there is scene at a transportation hub (train, airport, etc) and characters themselves say things that could be taken as domestic threats – out of context of course. You should have some expectation that your literary work is kept just as safe/secure while in the cloud as it is on your powered down hard drive or stack of papers on your desk. And we haven’t even touched on compliance, records retention, computer forensics, data recovery and many other litigating issues. The cases continue to play out and this blog entry only covers a couple of the challenges associated with Cloud Computing and the Law, but CloudFucius will keep an eye on it for ya. Many of the articles found while researching this topic: The Constitutional issues of cloud computing In digital world, we trade privacy for convenience Cloud Computing and the Constitution INTERNET LAW - Search and Seizure of Home Computers in Virginia Time to play catch-up on Internet laws: The gap between technology and America's laws hit home last week in a court decision on network neutrality FCC considers reclassification of Internet in push to regulate it Personal texting on a work phone? Beware your boss High Court Justices Consider Privacy Issues in Text Messaging Case Yahoo wins email battle with US Government How Twitter’s grant to the Library of Congress could be copyright-okay Judge Orders Google To Deactivate User's Gmail Account FBI Warrant Sought Google Apps Content in Spam Case State court rules company shouldn't have read ex-staffer's private e-mails District Took 56,000 Pictures From Laptops Can the Cloud survive regulation? Group challenging enhanced surveillance law faces uphill climb Watchdogs join 'Net heavyweights in call for privacy law reform Digital Due Process Judge's judgment called into question Dept of Justice Electronic Evidence and Search & Seizure Legal Resources Electronic Evidence Case Digest Electronic Evidence Finally, you might be wondering why CloudFucius went from A to C in his series. Well, this time we decided to jump around but still cover 26 interesting topics. And one from Confucius himself: I am not one who was born in the possession of knowledge; I am one who is fond of antiquity, and earnest in seeking it there. ps The CloudFucius Series: Intro, 1
