Cloud Concentration Brings Operational Risks

July 18, 2018

The sales job included a theme that the Internet is so decentralized that anything named cloud simply inherited all the good ‘ilities’ that massive decentralization might deliver. One of the core tenets of that Internet story-telling is about the resiliency that decentralization guarantees — as in: no single outage can cause problems for your cloud-delivered services.

The reality is that story is too often just nonsense. Google, Amazon, and Microsoft control enormous amounts of the infrastructure and operations upon which “cloud” services depend. When any of these three companies has an outage, broad swaths of “cloud-delivered” business services experience outages as well. If you are going to depend on cloud-enabled operations for your success, use care in how you define that success, and how your communicate about service levels with your customers. This is especially problematic for industries where customers have been trained to expect extremely high service levels — global financial services enterprises fall into this category.  Factor this risk into your business & technical plans.

Yesterday, Tuesday, July 17th, Google’s services that provide computing storage and data management tools for companies failed. The customers who depended upon those foundational services also failed. Snapchat and Spotify were two high profile examples, but the outages were far more widespread. Google services that also depend upon the storage and data management tools also failed. It appears that Google Cloud Networking was knocked down as the company reported “We are investigating a problem with Google Cloud Global Load balancers returning 502s for many services including AppEngine, Stackdriver, Dialogflow, as well as customer Global Load Balancers.” This has broad impact because all customers attempting to deliver high quality services depend on load balancers. It appears that this networking issue caused downstream outages like those experienced by Breitbart and Drudge Report.

This was the 5th non-trivial outage this year for Google’s AppEngine. Google’s ComputeEngine has had 7 outages this year, 12 for their Cloud Networking, 8 for their Stackdriver, 3 for Google Cloud Console, 3 for Cloud Pub/Sub, 4 for Google Kubernetes Engine, 2 for Cloud Storage, 4 for BigQuery, 2 for their DataStore, 2 for their Cloud Developer Tools, and 1 reported for their Identity & Security services.
To add insult, it appears that the Google Enterprise Support page may have also not working during the outage on the 17th…

Amazon also experienced service failures that were widely reported the day before (although they are not documented on the company’s service health dashboard).
Microsoft had “internal routing” failures that resulted in widespread service outages for over an hour on the 16th as well.

Plan this reality into your cloud-enabled strategies, architectures, designs, implementations, testing, monitoring, reporting, and contracts.

REFERENCES:
Google Cloud Status Dashboard
https://status.cloud.google.com/summary

Amazon Service Health Dashboard
https://status.aws.amazon.com/

Azure Status History
https://azure.microsoft.com/en-us/status/history/
Azure Status
https://azure.microsoft.com/en-us/status/
Office365 Health
https://portal.office.com/servicestatus

Google Cloud Has Disruption, Bringing Snapchat, Spotify Down
https://www.bloomberg.com/news/articles/2018-07-17/google-cloud-has-disruption-bringing-snapchat-spotify-down
By Mark Bergen, July 17, 2018

Spotify, Snapchat, and more are down following Google Cloud incident (update: fixed)
https://venturebeat.com/2018/07/17/discord-snapchat-and-more-are-down-following-google-cloud-incident/
Jeff Grubb, JULY 17, 2018

Google Cloud Platform fixes issues that took down Spotify, Snapchat and other popular sites
https://www.cnbc.com/2018/07/13/google-cloud-platform-reports-issues-snap-and-other-popular-apps-affe.html
Chloe Aiello, 07-17-2018

[Update: Resolved] Google Cloud has been experiencing an outage, resulting in widespread problems with several services
https://www.androidpolice.com/2018/07/17/google-cloud-experiencing-outage-resulting-widespread-problems-several-services/
By Ryne Hager, 07-17-2018

Google Enterprise Support page Outage Reference

Advertisements

Cloud File Sync Requires New Data Theft Protections

June 28, 2018

Microsoft Azure File Sync has been slowly evolving since it was released last year.
https://azure.microsoft.com/en-us/blog/announcing-the-public-preview-for-azure-file-sync/ and
https://docs.microsoft.com/en-us/azure/storage/files/storage-sync-files-deployment-guide?tabs=portal and https://azure.microsoft.com/en-us/roadmap/azure-file-sync/

The company also added “Azure:” [Azure Drive] to PowerShell to support discovery and navigation of all Azure resources including filesystems.
https://blogs.msdn.microsoft.com/powershell/2017/10/19/navigate-azure-resources-just-like-a-file-system/

Azure File Sync helps users keep Azure File shares in sync with their Windows Servers. Microsoft promotes the happy-path, where these servers are on-premise in your enterprise, but supports syncing with endpoints of any trust relationship.

What are my concerns?

The combination makes it much easier to discover Azure-hosted data and data exfiltration paths and then to get them set up to automatically ship new data into or out of your intended environment(s).  In other words, helping hostile parties to introduce their data or their malware into your organization’s Azure-hosted file systems, or helping hostile parties to steal your data while leaving a minimum of evidence describing who did what.

Why would I say that?

Many roles across global Financial Services enterprises are engaging in architecture risk analysis (ARA) as part of their day to day activities.  If we approach this topic like we were engaged in ARA fact finding, we might discover the following:

Too easy to share with untrustworthy endpoints:
It appears that anyone with the appropriate key (a string) can access a given Azure File Share from any Azure VM on any subscription. What could go wrong?
Microsoft customers can use shared access signatures (SAS) to generate tokens that have specific permissions, and which are valid for a specified time interval. These shared access signature keys are supported by the Azure Files (and File Sync) REST API and the client libraries.
A financial services approach might permit Azure File drive Shares on a given private Virtual Network to be secured in a manner so it would be only available via the Virtual Network using a private IP address on that same network.
https://feedback.azure.com/forums/217298-storage/suggestions/5993281-azure-files-on-a-virtual-network

Weak audit trail:
If you need to mount the Azure file share over SMB, you currently must use the storage account keys assigned to the underlying Azure File Storage.
As a result, in the Azure logs and file properties the user name for connecting to a given Azure File share is the storage account name regardless of who is using the storage account keys. If multiple users connect, they have to share an account. This seems to make effective auditing problematic.  It also seems to violate a broad range of commitments we all make to regulators, customers, and other constituencies.
https://feedback.azure.com/forums/217298-storage/suggestions/33477253-keep-track-of-the-file-owner
This limitation may be changing. Last month Microsoft announced a preview of more identity and authorization options for interacting with Azure storage. Time will tell.
https://docs.microsoft.com/en-us/rest/api/storageservices/Authorization-for-the-Azure-Storage-Services and https://docs.microsoft.com/en-us/rest/api/storageservices/authenticate-with-azure-active-directory

Missing link(s) to Active Directory:
Azure Files does not support Active Directory directly, so those sync’d shares don’t enforce your AD ACLs.
Azure File Sync preserves and replicates all discretionary ACLs, or DACLs, (whether Active Directory-based or local) to all server endpoints to which it syncs. Because those Windows Server instances can already authenticate with Active Directory, Microsoft sells Azure File Sync as safe-enough (…to address that happy path).  Unfortunately, Azure File Sync will synchronize files with untrusted servers — where all those controls can be ignored or circumvented.
https://docs.microsoft.com/en-us/azure/storage/files/storage-files-faq#security-authentication-and-access-control

Requires weakening your hardened endpoints:
Azure File Sync requires that Windows servers host the AzureRM PowerShell module, which currently requires Internet Explorer to be installed. …Hardened server no more…
https://feedback.azure.com/forums/217298-storage/suggestions/31909372-add-support-for-server-core-installations-for-azur

Plans for public anonymous access:
Microsoft is planning to support public anonymous read access to files stored on Azure file storage via its REST interface.
https://feedback.azure.com/forums/217298-storage/suggestions/7188650-allow-anonymous-public-access-to-azure-file-storag and https://docs.microsoft.com/en-us/rest/api/storageservices/authenticate-with-azure-active-directory

Port 445 (again):
Azure file storage configuration is exposed via TCP port 445. Is it wise to begin opening up port 445 of your Microsoft cloud environment? Given the history of Microsoft vulnerabilities exposed on port 445, many will probably hesitate.
https://feedback.azure.com/forums/217298-storage/suggestions/15001032-allow-access-to-file-storage-configuration-to-use

Goal of hosting Windows File Server in Azure:
Microsoft intends to deliver Azure Files in a manner that ensures parity with Windows File Server.
https://feedback.azure.com/forums/217298-storage/suggestions/19693045-automatically-mount-an-azure-file-share-to-a-windo

What other potential issues or concerns should we investigate?

  • Does the Azure File Storage REST interface resist abuse well enough to support its use in specified use cases (since each use case will have given risks and opportunities)?
  • Can a given use case tolerate risks associated with proposed or planned Microsoft upgrades to Azure File Storage REST, Azure File Sync, or Azure:?
  • Are there impacts on or implications for the way we need to manage our Azure AD?
  • Others?

What do you think?

 


Deception Has a Place in Secure Software

April 1, 2018

Deception has been standard military practice for millennia.  Attackers and defenders employ deception for a variety of goals:

Deceive – Cause a person to believe what is not true
Degrade – Temporary reduction in effectiveness
Delay – Slow the time of arrival of forces or capabilities
Deny – Withhold information about capabilities
Destroy – Enemy capability cannot be restored
Disrupt – Interrupt or impede capabilities or systems
Divert – Force adversary to change course or direction
Exploit – Gain access to systems to collect or plant information
Neutralize – Render adversary incapable of interfering with activity
Suppress – Temporarily degrade adversary/tool below level to accomplish mission

The U.S. military uses what they call a “See, Think, Do” deception methodology.

The core idea is to manipulate the cognitive processes in the deception target’s mind that result in targeting decisions and in adversary actions that are advantageous to our operations, our tactical or strategic goals.  This methodology tends to result in looping through the following three questions:

(1) What does the target of our deceptive activities see when they observe our operations?
(2) What conclusions does that target draw from those observations?
(3) What action may the target take as a result of the conclusions based upon those observations?

Successful deception operations are those that do more than make the target “believe” or “think” that the deception is true.  Success also needs to result in action(s) or inaction that supports the our operational plan(s).

Deception tactics can target human attackers, their organizations, their code, or any set thereof.

It is standard practice across global financial services enterprise information security to implement layers of protections — never depending on only a single security device.  We are at a stage in the battle with global cybercrime that may demand we introduce deception as a new layer of defense.  When we architect, design, and implement our applications and systems, we may enhance our resistance to attack by employing tactics analogous to military deception to influence attackers and the hostile code they use.  This will not be quick or easy.

Who might you assign to this task?  Do not immediately regress to: “I wonder who is available.”  Like many security tasks, deception planning requires a relatively unique skillset.  We build and deploy our software in ways that expose a multitude of interfaces.  That practice results in complex and often numerous abuse cases.  Our worker will need to understand and analyze that matrix from a number of perspectives, and to project other’s thinking and actions into the future.  We might expect them to:

  1. Understand each component’s deception and other information operations/influence capabilities.
  2. Be intimately familiar with their organization’s missions and focus.
  3. Understand the concepts of centers of gravity, calculated risk, initiative, security, and surprise.
  4. Understand friendly and adversary intelligence systems and how they function.
  5. Possess technical understanding of intelligence sensors, the platforms on which they deploy, their reporting capabilities, and associated processing methodologies.
  6. Understand the psychological and cultural factors that might influence the adversary’s planning and decision making.
  7. Understand potential adversaries’ planning and decision-making processes (both formal and informal).
  8. Understand the assets that are available to support the deception.
It is more difficult than just that.  We live in a world of laws, regulations, contracts, and norms that will constrain our behaviors in ways that differ from what may be acceptable on other battlefields.  Our leaders and practitioners need to understand those limits and manage their activities in ways that align with our obligations.  This will require much more than technical and operational competence.  It requires a high level of maturity and a finely calibrated moral & ethical compass.  Superior deception campaigns will require careful planning, effective guard-rails, and serious management.
Darn!  Another difficult staffing challenge…
Get use to it if you want to deliver your applications to a user-base anywhere on the Internet, and/or if you want to run your business in the cloud — especially if your are a global financial services enterprise — you need to expand and enhance your threat resistance using deception.
What do you think?

REFERENCES:

“Influence Operations and the Internet: A 21st Century Issue Legal, Doctrinal, and Policy Challenges in the Cyber World.”
“JP 3-13.3, Operations Security.” 04 January 2012
http://www.dtic.mil/doctrine/concepts/concepts.htm

Cloud Risk Assessment Challenge Thoughts

February 3, 2018

Technology is often at the center of efforts to sell new business models. From some perspectives, “Cloud” is more about new business models than about technology-enabled capabilities. Over the last decade or more, “cloud” marketers and hypists have constructed intricate structures of propaganda that trap the unwary in a matrix, a fog, a web of artifice and deceit.[1]  I think that a “cloud first” belief system is misused in ways that sometimes results in excessive risk-taking.  Belief systems are tricky to deal with and can cause some to dismiss or ignore inputs that might impact core tenets or dogma.

My reading and first hand experience lead me to believe that many are willing to migrate operations to other people’s computers — “the cloud” — without clearly evaluating impacts to their core mission, their risk management story-telling, and risk posture. Too many cloud vendors remain opaque to risk assessment, while leaning heavily on assertions of “compliance” and alignment with additionally hyped ancillary practices [containers, agile, encryption, etc.].

None of this rant implies that all Internet-centric service providers are without value. My core concern is with the difficulty in determining the risks associated with using one or another of them for given global Financial Services use cases.  That difficulty is only amplified when some involved exist within a reality-resisting “cloud first” belief system.

Because some “cloud” business models are exceptionally misaligned with global Financial Services enterprise needs and mandates, it is critically important to understand them. A given “cloud” vendor’s attack surface combined with a prodigious and undisciplined risk appetite can result in material misalignment with Financial Services needs. Again, this does not invalidate all “cloud” providers for all use cases, it elevates the importance of performing careful, thorough, clear-headed, evidence-informed risk assessments.  In our business, we are expected, even required, to protect trillions of dollars of other people’s money, to live up to our long and short term promises, and to comply with all relevant laws, regulations, and contracts.  And we are expected to do so in ways that are transparent enough for customers, prospects, regulators, and others to determine if we are meeting their expectations.

  • Evidence is not something to be used selectively to support beliefs.
  • Research is not hunting for justifications of existing beliefs.
  • Hunt for evidence. Use your cognitive capabilities to evaluate it.
  • Soberly analyze your beliefs.
  • Let the evidence influence your beliefs.
  • When needed, build new beliefs.[2]

Effective risk management has little room for anyone captured within a given belief system or abusing the power to create one’s own reality.

This remains a jumbled and unfinished thought that I will continue to evolve here.

What do you think?

[1] Derived from a phrase by Michelle Goldberg.
[2] Thank you Alex Wall, Johnston, IA. Author of a Letter to the Editor in the Feb 3, 2018 Des Moines Register.


Two Mobile Security Resources

October 16, 2017
Although it should not have taken this long, I just ran across two relatively new resources for those doing Financial Services business in an environment infested with mobile devices.

If you are a mobile developer or if your organization is investing in mobile apps, I believe that you should [at a minimum] carefully and thoughtfully review the Study on Mobile Device Security by the U.S. Department of Homeland Security and the Adversarial Tactics, Techniques & Common Knowledge Mobile Profile by Mitre.  Both seem like excellent, up-to-date overviews. The Mitre publication should be especially valuable for Architecture Risk Analysis and threat analysis in virtually any mobile context.

REFERENCES:
“Study on Mobile Device Security.” April 2017, by the US Dept. of Homeland Security (125 pages)https://www.dhs.gov/sites/default/files/publications/DHS%20Study%20on%20Mobile%20Device%20Security%20-%20April%202017-FINAL.pdf
“Adversarial Tactics, Techniques & Common Knowledge Mobile Profile.” October 2017, by The MITRE Corporation https://attack.mitre.org/mobile/index.php/Main_Page

 


Low Profile Office 365 Breach Reported

August 18, 2017

A couple years ago I wrote:

“I am told by many in my industry (and some vendors) that ‘if we put it in the cloud it will work better, cheaper, be safer, and always be available.’ Under most general financial services use cases (as opposed to niche functionality) that statement seems without foundation.”

Although many individuals have become more sophisticated in the ways they pitch ‘the cloud’ I still hear versions of this story on a fairly regular basis…

Today I learned about a recent Office 365 service outage that reminded me that issues concerning our use of ‘cloud’ technology and the commitments we in the Global Financial Services business make to our customers, prospects, marketers, investors, and regulators seem to remain very much unresolved.

What happened?

According to Microsoft, sometime before 11:30 PM (UTC) on August 3rd 2017, the company introduced an update to the Activity Reports service in the Office 365 admin center which resulted in customers usage reports of one tenant being displayed in another tenant’s administrative portal.

Some customer o365 administrators noticed that the reported email and SharePoint usage for their tenants had spiked. When they investigated, the o365 AdminPortal (https://portal.office.com/adminportal/) displayed activity for users from one or more AzureAD domains outside their tenant. In the most general terms, this was a breach. The breach displayed names and email addresses of those users along with some amount of service traffic detail, for example, user named X (having email address userNameX@domainY.com) sent 193 and received 467 messages, as well as uploaded 9 documents to SharePoint, and read 45 documents in the previous week.

Some subset of those 0365 customers reported the breach to Microsoft.

Microsoft reported that at they disabled the Activity Reports services at 11:40 PM UTC the same day, and that they had a fix in place by 3:35 AM UTC.

Why should I care?

As Global Financial Services Enterprises we make a lot of promises (in varying degrees of formality) to protect the assets for which we are responsible and we promote our ethical business practices. For any one or our companies, our risk profile is rapidly evolving in concert with expanded use of a range of cloud services. Those risks appear in many forms. All of us involved in Global Financial Services need our security story-telling to evolve in alignment with the specific risks we are taking when we choose to operate one or another portion of our operations in ‘the cloud.’ In addition, our processes for detecting and reporting candidate “breaches” also need to evolve in alignment with our use of all things cloud.

In this specific situation it is possible that each of our companies could have violated our commitments to comply with the European GDPR (General Data Protection Regulations: http://www.eugdpr.org/), had it happened in August 2018 rather than August 2017. We all have formal processes to report and assess potential breaches. Because of the highly-restricted access to Office 365 and Azure service outage details, is seems easy to believe that many of our existing breach detection and reporting processes are no longer fully functional.

Like all cloud stuff, o365 and Azure are architected, designed, coded, installed, hosted, maintained, and monitored by humans (as is their underlying infrastructure of many and varied types).
Humans make mistakes, they misunderstand, they miscommunicate, they obfuscate, they get distracted, they get tired, they get angry, they ‘need’ more money, they feel abused, they are overconfident, they believe their own faith-based assumptions, they fall in love with their own decisions & outputs, they make exceptions for their employer, they market their services using language disconnected from raw service-delivery facts, and more. That is not the whole human story, but this list attempts to poke at just some human characteristics that can negatively impact systems marketed as ‘cloud’ on which all of us perform one or another facet of our business operations.

I recommend factoring this human element into your thinking about the value proposition presented by any given ‘cloud’ opportunity. All of us will need to ensure that all of our security and compliance mandated services incorporate the spectrum of risks that come with those opportunities. If we let that risk management and compliance activity lapse for too long, it could put any or all of our brands in peril.

REFERENCES:
“Data Breach as Office 365 Admin Center Displays Usage Data from Other Tenants.”
By Tony Redmond, August 4, 2017
https://www.petri.com/data-breach-office-365-admin-center

European GDPR (General Data Protection Regulations)
http://www.eugdpr.org/


Workforce Mobility = More Shoulder Surfing Risk

July 20, 2017

An individual recently alerted me to an instance of sensitive information being displayed on an application screen in the context of limited or non-existent business value. There are a few key risk management issues here – if we ship data to a user’s screen there is a chance that:

  • it will be intercepted by unauthorized parties,
  • unauthorized parties will have stolen credentials and use them to access that data, and
  • unauthorized parties will view it on the authorized-user’s screen.

Today I am most interested in the last use case — where traditional and non-traditional “shoulder surfing” is used to harvest sensitive data from user’s screens.

In global financial services, most of us have been through periods of data display “elimination” from legacy applications. In the last third of the 20th century United States, individual’s ‘Social Security Numbers’ (SSN) evolved into an important component of customer identification. It was a handy key to help identify one John Smith from another, and to help identify individuals whose names were more likely than others to be misspelled. Informtation Technology teams incorporated SSN as a core component of individual identity across the U.S. across many industries. Over time, individual’s SSNs became relatively liquid commodities and helped support a broad range of criminal income streams. After the turn of the century regulations and customer privacy expectations evolved to make use of SSN for identification increasingly problematic. In response to that cultural change or to other trigger events (privacy breach being the most common), IT teams invested in large scale activities to reduce dependence on SSNs where practical, and to resist SSN theft by tightening access controls to bulk data stores and by removing or masking SSNs from application user interfaces (‘screens’).

For the most part, global financial services leaders, application architects, and risk management professionals have internalized the concept of performing our business operations in a way that protects non-public data from ‘leaking’ into unauthorized channels. As our business practices evolve, we are obligated to continuously re-visit our alignment with data protection obligations. In software development, this is sometimes called architecture risk analysis (an activity that is not limited to formal architects!).

Risk management decisions about displaying non-public data on our screens need to take into account the location of those screens and the assumptions that we can reliably make about those environments. When we could depend upon the overwhelming majority of our workforce being in front of monitors located within workplace environments, the risks associated with ‘screen’ data leakage to unauthorized parties were often managed via line-of-sight constraints, building access controls, and “privacy filters” that were added to some individual’s monitors. We designed and managed our application user interfaces in the context of our assumptions about those layers of protection against unauthorized visual access.

Some organizations are embarked on “mobilizing” their operations — responding to advice that individuals and teams perform better when they are unleashed from traditional workplace constraints (like a physical desk, office, or other employer-managed workspace) as well as traditional workday constraints (like a contiguous 8, 10, or 12-hour day). Working from anywhere and everywhere, and doing so at any time is pitched as an employee benefit as well as a business operations improvement play. These changes have many consequences. One important impact is the increasing frequency of unauthorized non-public data ‘leakage’ as workforce ‘screens’ are exposed in less controlled environments — environments where there are higher concentrations of non-workforce individuals as well as higher concentrations of high-power cameras. Inadvertently, enterprises evolving toward “anything, anywhere, anytime” operations must assume risks resulting from exposing sensitive information to bystanders through the screens used by their workforce, or they must take measures to effectively deal with those risks.

The ever more reliable assumption that our customers, partners, marketers, and vendors feel increasingly comfortable computing in public places such as coffee shops, lobbies, airports and other types of transportation hubs, drives up the threat of exposing sensitive information to unauthorized parties.

This is not your parent’s shoulder surfing…
With only modest computing power, sensitive information can be extracted from images delivered by high-power cameras. Inexpensive and increasingly ubiquitous multi-core machines, GPUs, and cloud computing makes computing cycles more accessible and affordable for criminals and seasoned hobbyists to extract sensitive information via off-the-shelf visual analysis tools

This information exposure increases the risks of identity theft and theft of other business secrets that may result in financial losses, espionage, as well as other forms of cyber crime.

The dangers are real…
A couple years ago Michael Mitchell and An-I Andy Wang (Florida State University), and Peter Reiher (University of California, Los Angeles) wrote in “Protecting the Input and Display of Sensitive Data:”

The threat of exposing sensitive information on screen
to bystanders is real. In a recent study of IT
professionals, 85% of those surveyed admitted seeing
unauthorized sensitive on-screen data, and 82%
admitted that their own sensitive on-screen data could
be viewed by unauthorized personnel at times. These
results are consistent with other surveys indicating that
76% of the respondents were concerned about people
observing their screens, while 80% admitted that
they have attempted to shoulder surf the screen of a
stranger .

The shoulder-surfing threat is worsening, as mobile
devices are replacing desktop computers. More devices
are mobile (over 73% of annual technical device
purchases) and the world’s mobile worker
population will reach 1.3 billion by 2015. More than
80% of U.S. employees continues working after leaving
the office, and 67% regularly access sensitive data at
unsafe locations. Forty-four percent of organizations
do not have any policy addressing these threats.
Advances in screen technology further increase the risk
of exposure, with many new tablets claiming near 180-
degree screen viewing angles.

What should we do first?
The most powerful approach to resisting data leakage via user’s screens is to stop sending that data to those at-risk application user interfaces.

Most of us learned that during our SSN cleanup efforts. In global financial services there were only the most limited use cases where an SSN was needed on a user’s screen. Eliminating SSNs from the data flowing out to those user’s endpoints was a meaningful risk reduction. Over time, the breaches that did not happen only because of SSN-elimination activities could represent material financial savings and advantage in a number of other forms (brand, good-will, etc.).

As we review non-public data used throughout our businesses, and begin the process of sending only that required for the immediate use case to user’s screens, it seems rational that we will find lots of candidates for simple elimination.

For some cases where sensitive data may be required on ‘unsafe’ screens Mitchell, Wang, and Reiher propose an interesting option (cashtags), but one beyond the scope of my discussion today.

REFERENCES:
“Cashtags: Protecting the Input and Display of Sensitive Data.”
By Michael Mitchell and An-I Andy Wang (Florida State University), and Peter Reiher (University of California, Los Angeles)
https://www.cs.fsu.edu/~awang/papers/usenix2015.pdf


%d bloggers like this: