Svenn Dybvik

This is the eleventh edition of the ENISA Threat Landscape (ETL) report, an annual report on the status of the cybersecurity threat landscape. It identifies the top threats, major trends observed with respect to threats, threat actors and attack techniques, as well as impact and motivation analysis. It also describes relevant mitigation measures. This year’s work has again been supported by ENISA’s ad hoc Working Group on Cybersecurity Threat Landscapes (CTL).

https://www.enisa.europa.eu/publications/enisa-threat-landscape-2023/@@download/fullReport

https://www.enisa.europa.eu/

Warfare and Geopolitics are Fuelling Denial-of-Service Attacks

The European Union Agency for Cybersecurity (ENISA)’s new report on the Denial-of-Service (DoS) attacks threat landscape finds 66% of DoS attacks are politically motivated.

The analysis is based on 310 verified Denial-of-Service (DoS) incidents during the reporting period of January 2022 to August 2023. However, this total number only represents the incidents gathered from open sources.

A large-scale study is also included of publicly reported incidents. The study focuses on the motivations of attackers, their goals and the socio-political profiles of targets.

DOS attack threat landscape report 2023

Since the beginning of 2022, DoS attacks have turned into a novel and massive threat using new techniques and are fuelled by warfare motivations.

In the last few years, DoS attacks have become easier, cheaper and more aggressive than ever before. The emergence of new armed conflicts around the world acted as fuel to new waves of DoS attacks where newly formed threat actors pick and choose targets without fear of repercussions.

Objective of report:

To provide a better understanding of this type of threat by analysing the motivations and impact of the DoS attacks and raise awareness at the same time by suggesting prevention and remediation recommendations.

The research performed illustrates that most impacted sectors over the reported period covering January 2022 to August 2023 are associated with government services. These attacks stand as retaliation acts triggered by political decisions.

The report highlights that the last few years, DoS attacks have increased in number especially in the public administration and have become easier and more aggressive than before, largely due to geopolitical reasons. The current DoS threat landscape is greatly influenced by the emergence of the recent armed conflicts around the world and especially by the Russia-Ukraine War that fuelled new waves of DoS attacks where recently introduced threat actors select targets without the fear of repercussions.

The study also illustrates that while no sector is exempted from DoS attacks, the government infrastructure has become a preferred target by threat actors that often manage to be successful by causing downtime.

KEY TAKEAWAYS

The most affected sector was the government administration sector, accounting for receiving 46% of attacks.
It is estimated that 66% of the attacks were motivated by political reasons or activist agendas.
Overall, 50% of the global incidents were found to be related to the Russian-Ukrainian war.
The study shows that 8% of the attacks caused total disruption in the target.
The analysis of DoS attacks' motivations and goals is based on the new taxonomy used to classify such attacks based on information publicly available about the attacks the targets for a more systematic analysis approach.
Warfare is a key gameplayer and organisations would benefit from prevention and remediation strategies.
Reporting of DoS attacks has not reached the maturity needed to allow for the real extent and impact of such attacks.

Key challenges

The detection, description and analysis of DoS attacks is highly complex and different from other cybersecurity attacks. In other types of cybersecurity attacks, such as exploitation of services or even supply chain attacks, the attackers leave artefacts behind that the incident responders can find, analyse, share, confirm, verify and ultimately use for some explanation or even attribution. In the case of DoS attacks artefacts do not exist or are usually fake ones. This is part of the reasons why official databases of such attacks are difficult to be compiled.

The report sheds light on 3 types of information one must be warned against when seeking to analyse DoS incidents:

The good quality of information: paradoxically, this is the information coming from reports and claims made by the attackers themselves.
The bad quality of information: information coming from DoS protection providers that actually stopped the attacks.
The ugly quality of information: information coming from reports created by the targets.

What is a Denial-of-Service or DoS attack?

There is a wide range of difficulties when it comes to defining what a DoS attack is.

Denial-of-service attacks (DoS) are defined for this report as availability attacks in which attackers, partially or totally, obstruct the legitimate use of a target's service by depleting or exploiting the target's assets over a period of time.

A Distributed Denial-of-Service (DDoS) attack DDoS is a subset of DoS attacks. DoS attacks can be distributed which means that they may originate from thousands of sources from all over the world, usually relying on large-scale botnets or proxies.

Further Information

ENISA Threat Landscape for DoS Attacks - 2023

ENISA Threat Landscape - 2023

Contact

For press questions and interviews, please contact press (at) enisa.europa.eu

Stay updated - subscribe to RSS feeds of both ENISA news items & press releases!

News items:

http://www.enisa.europa.eu/media/news-items/news-wires/RSS

PRs:

http://www.enisa.europa.eu/media/press-releases/press-releases/RSS

https://www.enisa.europa.eu/news/checking-up-on-health-ransomware-accounts-for-54-of-cybersecurity-threats

Checking-up on Health: Ransomware Accounts for 54% of Cybersecurity Threats

The European Union Agency for Cybersecurity (ENISA) releases today its first cyber threat landscape for the health sector. The report found that ransomware accounts for 54% of cybersecurity threats in the health sector.

The comprehensive analysis maps and studies cyberattacks, identifying prime threats, actors, impacts, and trends for a period of over 2 years, providing valuable insights for the healthcare community and policy makers. The analysis is based on a total of 215 publicly reported incidents in the EU and neighbouring countries.

Executive Director of the European Union Agency for Cybersecurity (ENISA), Juhan Lepassaar, said: “A high common level of cybersecurity for the healthcare sector in the EU is essential to ensure health organisations can operate in the safest way. The rise of the covid-19 pandemic showed us how we critically depend on health systems. What I consider as a wake-up call confirmed we need to get a clear view of the risks, the attack surface and the vulnerabilities specific to the sector. Access to incident reporting data must therefore be facilitated to better visualise and comprehend our cyber threat environment and identify the appropriate mitigation measures we need to implement.”

The findings

The report reveals a concerning reality of the challenges faced by the EU health sector during the reporting period.

Widespread incidents. The European health sector experienced a significant number of incidents, with healthcare providers accounting for 53% of the total incidents. Hospitals, in particular, bore the brunt, with 42% of incidents reported. Additionally, health authorities, bodies and agencies (14%), and the pharmaceutical industry (9%) were targeted.
Ransomware and data breaches. Ransomware emerged as one of the primary threats in the health sector (54% of incidents). This trend is seen as likely to continue. Only 27% of surveyed organisations in the health sector have a dedicated ransomware defence programme. Driven by financial gain, cybercriminals extort both health organisations and patients, threatening to disclose data, personal or sensitive in nature. Patient data, including electronic health records, were the most targeted assets (30%). Alarmingly, nearly half of all incidents (46%) aimed to steal or leak health organisations' data.
Impact and lessons learned by the COVID-19 Pandemic. It is essential to note that the reporting period coincided with a significant portion of the COVID-19 pandemic era, during which the healthcare sector became a prime target for attackers. Financially motivated threat actors, driven by the value of patient data, were responsible for the majority of attacks (53%). The pandemic saw multiple instances of data leakage from COVID-19-related systems and testing laboratories in various EU countries. Insiders and poor security practices, including misconfigurations, were identified as primary causes of these leaks. The incidents serve as a stark reminder of the importance of robust cybersecurity practices, particularly in times of urgent operational needs.
Vulnerabilities in Healthcare Systems. Attacks on healthcare supply chains and service providers resulted in disruptions or losses to health organisations (7%). Such types of attacks are expected to remain significant in the future, given the risks posed by vulnerabilities in healthcare systems and medical devices. A recent study by ENISA revealed that healthcare organisations reported the highest number of security incidents related to vulnerabilities in software or hardware, with 80% of respondents citing vulnerabilities as the cause of more than 61% of their security incidents.
Geopolitical Developments and DDoS Attacks. Geopolitical developments and hacktivist activity led to a surge in Distributed Denial of Service (DDoS) attacks by pro-Russian hacktivist groups against hospitals and health authorities in early 2023, accounting for 9% of total incidents. While this trend is expected to continue, the actual impact of these attacks remains relatively low.
The incidents examined in the report had significant consequences for health organisations, primarily resulting in breaches or theft of data (43%) disrupted healthcare services (22%) and disrupted services not related to healthcare (26%). The report also highlights the financial losses incurred, with the median cost of a major security incident in the health sector estimated at €300,000 according to the ENISA NIS Investment 2022 study.
Patient safety emerges as a paramount concern for the health community, given potential delays in triage and treatment caused by cyber incidents.

New report from the NIS Cooperation Group

The NIS Cooperation Group releases today its report on “Threats and risk management in the health sector – Under the NIS Directive”. As a first assessment on the measures currently in place, the study sheds light on the different cybersecurity challenges in risk mitigation faced by the EU health sector. Together with relevant threat taxonomies and cyber incident data, the report discloses business continuity and mitigation recommendations to limit the likelihood and impacts of a cyber related incident.

Background

The ENISA threat landscape reports map the cyber threat landscape to help decision makers, policy makers and security specialists define strategies to defend citizens, organisations and cyberspace.

The report’s content is gathered from open sources such as media articles, expert opinions, intelligence reports, incident analysis and security research reports; as well as through the members of the ENISA Cyber Threat Landscapes Working Group (CTL working group).

The analysis and views of the threat landscape by ENISA is meant to be industry and vendor neutral. Information based on OSINT (Open-Source Intelligence) and the work of ENISA on Situational Awareness also helped document the analysis presented in the report.

Further Information

Health Threat Landscape – ENISA report 2023

ENISA topic: Health

ENISA topic: Cyber threats

CSIRT capabilities in healthcare sector – ENISA report 2021

Cloud security for healthcare services – ENISA report 2021

Procurement guidelines for cybersecurity in hospitals

References

https://www.enisa.europa.eu/about-enisa/data-protection

▼

ENISA is committed to the protection of individuals’ privacy and data protection.

The rights to privacy and data protection are fundamental rights, set out in articles 7 and 8 of the EU Charter of Fundamental Rights.

ENISA, as an EU Agency, is subject to the Regulation (EU) 2018/1725 on the protection of natural persons with regard to the processing of personal data by the Union institutions, bodies, offices and agencies. This Regulation has the same level and types of rules for the protection of personal data as the General Data Protection Regulation (GDPR), which is applicable to all EU Member States.

In order to function and meet its tasks and objectives, ENISA needs to collect and further process personal data of its staff members, as well as other natural persons in the context of its different activities in the areas of human resources, procurement and finance, corporate services (e.g. IT services), as well as in the context of the functioning of ENISA’s governance bodies and core operations.

What is personal data?

Personal data is any information relating to an identified or identifiable natural person. An identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identifier, such as a name, an identification number, location data, an online identifier or to one or more factors specific to his or her physical, physiological, genetic, mental, economic, cultural or social identity.

Examples of personal data include: names, pictures, contact details, emails, CVs, diplomas, recommendation letters, professional & family life, bank details, transaction information, medical data, judicial & criminal records, CCTV footage, log files, IP addresses, cookies, etc.

How does ENISA process personal data?

ENISA process personal data in accordance with the principles and provisions of Regulation (EU) 2018/1725.

These provisions mandate the personal data shall be:

processed lawfully, fairly and in a transparent manner;
collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes (“purpose limitation”);
adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (“data minimisation”);
accurate and, where necessary, kept up to date (“accuracy”’);
kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed (‘storage limitation’);
processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).

ENISA adheres to its obligations under the Regulation (EU) 2018/1725 and provides for the data subjects rights under this Regulation.

Further information:

ENISA’s central register of data processing activities

Data subjects rights under Regulation (EU) 2018/1725

ENISA’s Data Protection Officer

Data protection with regard to ENISA’s website

https://cybersecuritymonth.eu/

https://cybersecuritymonth.eu/press-campaign-toolbox/visual-identity/banners/ecsm-partnerstoolkit.zip

https://cybersecuritymonth.eu/smarterthanahacker

https://privacyforum.eu/

https://www.enisa.europa.eu/publications/pseudonymisation-techniques-and-best-practices

Pseudonymisation techniques and best practices

This report explores further the basic notions of pseudonymisation, as well as technical solutions that can support implementation in practice. Starting from a number of pseudonymisation scenarios, the report defines first the main actors that can be involved in the process of pseudonymisation along with their possible roles. It then analyses the different adversarial models and attacking techniques against pseudonymisation, such as brute force attack, dictionary search and guesswork. Moreover, it presents the main pseudonymisation techniques and policies available today.

https://www.enisa.europa.eu/publications/pseudonymisation-techniques-and-best-practices/@@download/fullReport

https://www.enisa.europa.eu/publications/data-pseudonymisation-advanced-techniques-and-use-cases

Data Pseudonymisation: Advanced Techniques and Use Cases

This report, building on the basic pseudonymisation techniques, examines advanced solutions for more complex scenarios that can be based on asymmetric encryption, ring signatures and group pseudonyms, chaining mode, pseudonyms based on multiple identifiers, pseudonyms with proof of knowledge and secure multi-party computation. It then applies some of these techniques in the area of healthcare to discuss possible pseudonymisation options in different example cases. Lastly, it examines the application of basic pseudonymisation techniques in common cybersecurity use cases, such as the use of telemetry and reputation systems.

https://www.enisa.europa.eu/publications/data-pseudonymisation-advanced-techniques-and-use-cases/@@download/fullReport

https://www.enisa.europa.eu/publications/engineering-personal-data-sharing

Engineering Personal Data Sharing

This report attempts to look closer at specific use cases relating to personal data sharing, primarily in the health sector, and discusses how specific technologies and considerations of implementation can support the meeting of specific data protection. After discussing some challenges in (personal) data sharing, this report demonstrates how to engineer specific technologies and techniques in order to enable privacy preserving data sharing. More specifically it discusses specific use cases for sharing data in the health sector, with the aim of demonstrating how data protection principles can be met through the proper use of technological solutions relying on advanced cryptographic techniques. Next it discusses data sharing that takes place as part of another process or service, where the data is processed through some secondary channel or entity before reaching its primary recipient. Lastly, it identifies challenges, considerations and possible architectural solutions on intervenability aspects (such as the right to erasure and the right to rectification when sharing data).

https://www.enisa.europa.eu/publications/engineering-personal-data-sharing/@@download/fullReport

https://www.enisa.europa.eu/news/securing-personal-data-in-the-wake-of-ai

Securing Personal Data in the Wake of AI

This year’s Annual Privacy Forum focused on pressing personal data protection challenges raised by the ever faster-paced developments witnessed today in digital technologies and legislative initiatives.

Organised by the European Union Agency for Cybersecurity (ENISA) together with the directorate general of the European Commission for communications networks, content and technology (DG Connect) and the National Institute for Research in Digital Science and Technology (INRIA), the 2023 edition of the event took place in Lyon, France.

This 11^th edition brought together a total of 26 speakers and over 400 participants both physically and remotely.

Panels of experts were given the chance to address some of the most pressing topics in relation to the securing of personal data, including:

Emerging Technologies for personal data protection;
Machine learning and personal data processing;
Personal data sharing under the European Data Strategy;
Promoting GDPR compliance and data subject rights.

European Union Agency for Cybersecurity, Executive Director Juhan Lepassaar, commented: “ENISA has been analysing AI risks for the last 5 years. To prepare for a secure and trusted AI, the safeguards need to be in place. Today AI and in particular machine learning pose great challenges to data protection and privacy. Trust is what underpins the secure adoption and maturity of these technologies. Personal data protection measures are an impactful way to gaining this trust.”

Wojciech Wiewiorowski, European Data Protection Supervisor: “It would be reductive to not look at the benefits that AI can bring to society, such as faster decision making and easy-to-use automation. However, the risks to individual rights are significant and can have a profound impact on our democracies. By proactively addressing these risks, we can harness the potential of AI while safeguarding privacy rights. It is crucial to take action now to ensure responsible and ethical implementation of AI technologies.”

Challenges and opportunities: the conference’s key take-aways

Within the three panel discussions, regulators from EU Institutions, France, Spain and Norway together with policy makers and industry practitioners, debated on which are the data protection engineering challenges for the years to come, what is the role of Data Protection Authorities in the artificial intelligence era and the data protection prospects and contemplations when processing medical data in the post pandemic era.
Further to these discussions, invited speakers also elaborated on the AI regulatory approaches on artificial intelligence across the two sides of the Atlantic and how Zero Knowledge Proof technique can be deployed as a privacy enhancing technique in real life applications.

The Annual Privacy Forum was co-located and organised back to back with the EDPS IPEN workshop as part of their strategic cooperation and the Memorandum of Understanding signed between ENISA and the EDPS in 2022.

Further Information

Relevant ENISA publications:

Engineering Personal Data Sharing – ENISA report 2023
Data Protection Engineering – ENISA report 2022
Deploying pseudonymisation techniques
Data Pseudonymisation: Advanced Techniques and Use Cases
Pseudonymisation techniques and best practices
ENISA topic – Data Protection

Other information:

About the Annual Privacy Forum

The Annual Privacy Forum (APF) has become a renowned forum among policy-makers, researchers and industry stakeholders in the area of privacy and personal data protection who join forces to advance information security. The forum is set against the EU legislative background that is mainly, but not exclusively, comprised of the GDPR and the draft ePrivacy Regulation. The event sets the stage for new research proposals, solutions, models, applications and policies. In the last few years, the forum has also developed a deeper industry footprint to complement its original research and policy orientation.

About the European Union Agency for Cybersecurity (ENISA)

The EU Agency for Cybersecurity has been working in the area of privacy and data protection since 2014, by analysing technical solutions for the implementation of the GDPR, privacy by design and security of personal data processing. The Agency has been providing guidance on data pseudonymisation solutions to data controllers and processors since 2018.

Contact

For press questions and interviews, please contact press (at) enisa.europa.eu

Allmänt · ‽IT · ∴ · interrobangit · § · §IT

Dela · Kommentera

:

Kommentera

Av Svenn Dybvik - 7 maj 2023 00:00

https://www.ncsc.gov.uk/

The National Cyber Security Centre

https://www.ncsc.gov.uk/collection/problem-book/hardware-security

https://www.ncsc.gov.uk/collection/cloud/using-cloud-services-securely/how-to-lift-and-shift-successfully

https://www.ncsc.gov.uk/collection/defending-democracy/guidance-for-high-risk-individuals

https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development

https://www.ncsc.gov.uk/section/information-for/individuals-families

https://www.ncsc.gov.uk/section/information-for/self-employed-sole-traders

https://www.ncsc.gov.uk/section/information-for/small-medium-sized-organisations

https://www.ncsc.gov.uk/section/information-for/large-organisations

https://www.ncsc.gov.uk/section/information-for/public-sector

https://www.ncsc.gov.uk/section/information-for/cyber-security-professionals

https://www.ncsc.gov.uk/collection/defending-democracy

Defending democracy

Introduction

This collection brings together expanded guidance to raise awareness of the cyber threats to democratic processes, institutions, and the people involved in them. The aim is to prevent or reduce related attacks against both organisations and individuals.

The context here is the threat of foreign cyber interference with the aim of influencing UK democratic processes. Democratic events such as elections are attractive targets for adversaries, and organisations and individuals must be prepared for threats, old and new. Defending UK democratic institutions and processes is a priority.

Who is this guidance for?

Organisations

political parties or organisations, think tanks
local authorities, central government, devolved administrations

Individuals

working in organisations as above, that puts them at higher risk of targeting
working in IT or SOC roles in organisations as above

This collection contains

Guidance for high-risk individuals
There has been a rise in targeting of individuals’ personal accounts instead of corporate ones, as security is less likely to be managed by a dedicated team. This is not a mass campaign against the public but a persistent effort to target people whom attackers consider to hold information of interest. This guidance sets out how individuals can protect their accounts and devices.

Further guidance will be added to this collection in 2024.

Guidance for high-risk individuals on protecting your accounts and devices

What is a high-risk individual?

In a cyber security context, you are considered a high-risk individual if your work or public status means you have access to, or influence over, sensitive information that could be of interest to nation state actors.

High-risk individuals include those working in political life (including elected representatives, candidates, activists and staffers), academia, journalism and the legal sector.

In recent years there have been a number of targeted cyber attacks against high-risk individuals in the UK, to attempt to gain access to their accounts and devices. This has resulted in the theft and publication of sensitive information, which can also cause reputational damage.

How and why you may be targeted

There are different ways an attacker may gain access to your accounts or devices. Spear-phishing is one method that attackers have used in the past to compromise high-risk individuals.

A joint NCSC advisory with international partners describes this technique and warns of a state actor that has targeted high-risk individuals in the UK in this way.

Using this guidance

This guidance will help you improve the security of personal accounts and devices, and keep you better protected online.

Personal accounts and devices are the responsibility of the individual and may be considered an easy target for threat actors, as they may perceive them to have fewer security measures in place.

As far as possible, you should continue to use corporately managed accounts and devices for your work, as they will be centrally managed and secured.

Protecting your accounts

Your personal accounts are a likely target for attackers. If an attacker gains access to one of your accounts, they may be able access to the information on them. Taking the actions below will significantly reduce the chance of a successful attack.

Use strong passwords

When an attacker compromises an account, it is often because they have either stolen or guessed the password. Weak passwords are vulnerable to attack. Research shows that weak passwords often contain names, places or a run of numbers. The more complex a password is, the more secure it becomes. The NCSC recommends using a sequence of three random words to make a password complex but easy to remember.

Having strong passwords can lessen the chance that your account is compromised. Important accounts that contain sensitive information (such as your personal and work email, social media and online banking) should have a strong password that is unique to that account.

It can be difficult to remember passwords, so it’s fine to write them down and keep them safe where other people can’t access them, separate from your devices. You can also use a password manager. Password managers are a convenient and secure way to store your passwords, either in your browser or an app, which uses one ‘master’ password or biometrics. Both Android and iOS devices have secure and trusted password manager functions built in:

Accessing password manager functions on IOS (Apple)

Accessing password manager functions on Android

You should not share your passwords for any of your accounts. Password sharing heightens the risk of account compromise and weakens your online security.

Enable two-step verification on your accounts

Setting up two-step verification or 2SV (also known as multi-factor authentication or two-factor authentication) on an account makes it considerably more secure. It means that even if an attacker knows your password, they can’t access your account. It works by asking you to complete a second step when you sign in, usually by entering a code sent by SMS, email or via an app. Authentication apps such as Google Authenticator or Microsoft Authenticator are designed just for this purpose, and are more secure and convenient than SMS.

For some accounts, you can choose to only use 2SV when signing in from a new device or changing your password. This means you don’t have to enter a code every time you use a service.

Where should I set up 2SV?

You should set up 2SV on all personal accounts that could be considered a high-value target for an attacker, such as your email, messaging apps like WhatsApp, and social media. If 2SV isn’t available on an account, make sure it has a strong and unique password or consider changing to a service that offers 2SV.

The NCSC has separate guidance to help you set up 2SV.

Receiving 2SV requests

If you receive a 2SV request that asks if you are trying to access your account but you are not trying to log in, do not grant permission. It's possible that an attacker knows your password and is trying to access your account. In this instance, 2SV is doing its job, but you should change your password. If you use the same password on other accounts, you should change it for them too.

Never share an access code with others, even if prompted, as this can give attackers control of your account.

Review your social media use and settings

Consider how much personal information you are sharing on social media. Attackers may use the information you post to engineer a spear-phishing attack and attempt to gain access to your account and data.

You should also consider maintaining separate professional and personal social media accounts.

You can review the privacy settings for each account to decide what is most appropriate for you. The major platforms provide instructions on how to manage your privacy settings. You can find links to these instructions in the NCSC guidance on using social media safely, alongside additional information on managing your digital footprint and spotting fake accounts.

Be aware that attackers may pose as other people on social media platforms, even if you appear to have mutual contacts. They may seek to cause you reputational damage, by sending you malicious links to click to gain access to sensitive information. It’s possible that over the next few years, attackers may also make increasing use of voice clones or ‘deep fakes’ to trick users to reveal sensitive information.

The UK National Protective Security Authority has guidance about false profiles that helps you spot them on social media and professional networking sites.

For any public social media accounts that you use in a professional context, consider using a social media management service. This means that colleagues or employees will be able to create posts for you without you sharing your passwords. You should avoid using the same password for the management service as any of your social media accounts connected to it. You can read the NCSC guidance on protecting what you publish for further information.

Review your use of messaging apps

Messaging apps such as WhatsApp, Messenger and Signal are now an important part of how we communicate in everyday life. It's important to use them securely and pay special attention when connecting with people professionally.

If you use a messaging app for personal use on a personal device, you should consider the following:

use disappearing messages that automatically delete after a set period – by turning this on you will limit what a successful attacker could access if they do manage to get in
consider the recipient – are they who they say they are, and who else is in the chat group?
avoid accepting message requests from unknown accounts – consider calling first to verify who they are

As with all apps, you should make sure that the latest security updates are installed and set up two-step verification (2SV) for when you log in.

Protecting your devices

As with your accounts, attackers may also try to compromise your devices – computers, phones or tablets – to achieve their aims. If they manage to access them, they can steal sensitive or personal information, carry out monitoring, or even impersonate you.

There are several things you can do to secure your devices.

Install updates

Installing security updates promptly is one of the most important things you can do to protect yourself from a cyber attack.

Out-of-date software, apps and operating systems often contain security vulnerabilities, and vendors regularly release updates to fix them. So if you receive a prompt to update your device or apps, you should do it, as it will prevent attackers taking advantage of these security flaws.

Most apps offer an auto-update option, meaning that updates will automatically download when they are available (or when you next connect to wifi), and install at the earliest time suitable for you, or the next time the device restarts. You should make sure this option is enabled on your device. You can read the NCSC guidance on software and app updates to help you enable automatic updates for popular devices and services.

You should only download software and apps from official stores, like Google Play or Apple App Store. They scan software for viruses before making it available, giving you more reassurance that what you’re downloading is safe

Use 'Lockdown Mode'

For additional security, you should consider enabling Lockdown Mode for your Apple devices. Lockdown Mode has been designed for individuals who might be targeted by sophisticated threat actors. On Windows devices, you have the option to enable ‘S mode’ which only allows applications from the Microsoft Store to be downloaded and installed. This prevents malicious programs running on your device.

Replace old devices

As older devices are replaced by newer models, vendors stop releasing security updates, making them more vulnerable to attack. You should avoid using devices that are no longer supported and upgrade your device if support is ending soon.

You can check to see if you device is still supported with the Which? phone support checker tool.

Protect physical access

You should protect your devices with a password or pin that must be entered when the device is powered on or restarted. This will help prevent someone who has managed to get physical access to your device accessing the information on it.

To unlock from standby, you can also use a password, PIN or a biometric, such as a fingerprint or facial recognition. Use whichever method you find convenient.

Avoid plugging your devices into public USB charging points, and instead use a traditional power plug.

Most devices come with a feature that allows you to track the location of a device and remotely wipe it if it's lost or stolen. On an iPhone, make sure Find My is turned on, and for Android devices, enable Find My Device.

Know how to erase data from devices

Our devices often contain sensitive work, personal and financial data, which can still be recovered even if the files have been deleted. So it's important to know how to erase the data if a device is lost or stolen, or you permanently give it to someone else to use. The NCSC has guidance to help you securely erase data on your devices.

What to do if you think you've been attacked

If you receive a suspicious email, do not click on any links, or reply to the email, until you're certain the sender is genuine. The NCSC has guidance on how to spot and deal with phishing emails.

If you receive a suspicious email you should report it to your organisation’s IT support team, who will be able to offer advice, even if has been sent to a personal account.

If you have clicked on a link, or think you’ve been hacked, don’t panic, even if you think you have made a mistake. If something goes wrong on a device or account that your organisation has provided, report it to IT support. The security team shouldn’t blame you for reporting that something has happened to you, as it helps them fix things, and try to stop it happening again, to you or anyone else.

Topics

https://www.ncsc.gov.uk/section/advice-guidance/all-topics?topics=Device

https://www.ncsc.gov.uk/section/advice-guidance/all-topics?topics=Personal%20data

https://www.ncsc.gov.uk/section/advice-guidance/all-topics?topics=Social%20media

https://www.ncsc.gov.uk/section/information-for/individuals-families

Individuals & families

What is cyber security?

Cyber security is the means by which individuals and organisations reduce the risk of being affected by cyber crime.

Cyber security's core function is to protect the devices we all use (smartphones, laptops, tablets and computers), and the services we access online - both at home and work - from theft or damage. It's also about preventing unauthorised access to the vast amounts of personal information we store on these devices, and online.

Cyber security is important because smartphones, computers and the internet are now such a fundamental part of modern life, that it's difficult to imagine how we'd function without them. From online banking and shopping, to email and social media, it's more important than ever to take steps that can prevent cyber criminals getting hold of our accounts, data, and devices.

Cyber Aware and staying secure online

From banking to shopping, and streaming to social media, people are spending more time than ever online. Cyber Aware is the government's advice on how to stay secure online.

https://www.ncsc.gov.uk/cyberaware

Protecting your data and devices

https://www.ncsc.gov.uk/guidance/data-breaches

How to protect yourself from the impact of data breaches

https://www.ncsc.gov.uk/guidance/buying-selling-second-hand-devices

How to erase the personal data from your phone, tablets, and other devices

https://www.ncsc.gov.uk/guidance/smart-security-cameras-using-them-safely-in-your-home

How to protect 'smart' security cameras and baby monitors from cyber attack.

https://www.ncsc.gov.uk/guidance/securing-your-devices

How to ensure your devices are as secure as possible.

https://www.ncsc.gov.uk/guidance/video-conferencing-services-using-them-securely

How to set up and use video conferencing services, such as Zoom and Skype, safely and securely

https://www.ncsc.gov.uk/information/5g-explainer

A summary of what 5G is, how it will affect the UK and how the NCSC is helping to secure it.

https://www.ncsc.gov.uk/guidance/online-gaming-for-families-and-individuals

How to enjoy online gaming securely by following just a few tips

https://www.ncsc.gov.uk/guidance/shopping-online-securely

How to shop safely online.

https://www.ncsc.gov.uk/guidance/what-is-an-antivirus-product

Detect and prevent malicious software and viruses on your computer or laptop.

https://www.ncsc.gov.uk/guidance/social-media-how-to-use-it-safely

Use privacy settings across social media platforms to manage your digital footprint.

https://www.ncsc.gov.uk/guidance/sextortion-scams-how-to-protect-yourself

Advice in response to the increase in sextortion scams

https://www.ncsc.gov.uk/guidance/smart-devices-in-the-home

Many everyday items are now connected to the internet: we explain how to use them safely.

https://www.ncsc.gov.uk/guidance/using-tls-to-protect-data

Using TLS to protect data

Recommended profiles to securely configure TLS for the most common versions and scenarios, with additional guidance for managing older versions.

Allmänt · ‽IT · ∴ · interrobangit · § · §IT

Dela · Kommentera

:

Kommentera

Av Svenn Dybvik - 30 april 2023 00:00

https://www.ncsc.gov.uk/collection/application-development

Application development

Recommendations for the secure development, procurement and deployment of generic and platform-specific applications.

PAGE 1 OF 16

Introduction

Advice on how to minimise the loss of data from applications running on devices handling sensitive data.

It is primarily for risk assessors and application developers, and contains recommendations for the secure development, procurement and deployment of generic and platform-specific applications.

We recommend that you read the generic application development section of this guidance in full, before you read the platform-specific guidance sections.
Note that the NCSC does not provide services for the assessment of third-party applications; organisations must undertake this work on an individual, per-application basis.

About this guidance

This guidance will help you to:

ensure sensitive data is protected appropriately when stored and transmitted
minimise the opportunity for accidental data leakage across application boundaries
ensure only authorised parties can access sensitive information
maximise the usability of applications whilst maintaining security in the development phase
restrict access to sensitive data to those applications designed to handle such material in a secure manner

In achieving these goals, the following assumptions are made:

devices are configured in line with the NCSC End User Device guidance
devices could have other third-party applications installed
devices will be in a locked state if lost or stolen
attackers can gain total control of devices (such as through jailbreaking/rooting) or otherwise gaining administrative privileges

In addition, the following principles are followed throughout:

applications that store, process, handle, or have network access to sensitive information should be developed with security in mind from the start, and should be audited and assessed before use
use the functionality of modern platforms to enhance the security of applications (this is the focus of the platform-specific guidance)
if sensitive information is stored using the platform’s native functionality, then third-party applications may be able to access that information
the specific data that applications can access (and the constraints are involved) must be understood with respect to each platform’s security model

PAGE 2 OF 16

Generic application development

Recommendations for the secure development, procurement and deployment of generic applications.

This guidance provides advice on how to minimise the loss of data from applications running on devices handling sensitive data. It is primarily for risk assessors and application developers, and contains recommendations for the secure development, procurement and deployment of generic applications.

The guidance below is platform-agnostic, and describes how to mitigate common security issues, regardless of the platform used. We recommend that you read this generic application development guidance in full, before you read the platform-specific guidance.

Common security issues

When building an application, you should use the security mechanisms built into the native platform. Common security issues can be grouped into the following three areas:

Secure data handling
Application hardening
Third party applications

Secure data handling

Data storage APIs

You should not store sensitive information on a device when it's not required. If it must be stored on a device, make use of any native data storage protection APIs available on the platform.
Make a model of the data flow in and out of the device, taking into consideration realistic threats that the system (and its users) may encounter. Most platforms provide documented APIs that allow data to be stored with different levels of protection.
Always encrypt sensitive information when stored, protected by an authentication mechanism such as a passcode or platform-specific equivalent. When the sensitive data is no longer required on the device, it should be securely removed.
Ensure the applications allows administrators to delete sensitive data from devices if they are compromised or lost.

Cryptography

Secure implementation of cryptographic functions requires significant effort to properly design and verify, so wherever possible use native capabilities available on the platform.
If using non-native cryptographic schemes, ensure they are reviewed and tested by third party experts.
Storing cryptographic keys on the device will reduce the effectiveness of an additional cryptographic layer (as keys stored locally could be recovered from the device). Storing the keys on a remote server would prevent an attacker with physical access to the device from retrieving them. Users should be required to authenticate to the server. Alternately, you can use TPMs (trusted platform modules) and secure enclaves to improve the security of stored keys.

Data access authorisation

Store sensitive information securely, and hide it from the user until they have been authenticated (and authorised) to view it.
Perform user authentication using the native platform mechanisms, with each account being linked to an individual.
Where practical, manage user accounts centrally.
When the application has lost focus (or been backgrounded for a short amount of time), the authentication process should be repeated to ensure the identity or permissions of the current user have not changed.

Secure data transmission

Send any sensitive information transferred between device and server using an appropriate encryption mechanism. All modern platforms have built-in support for transport layer security (TLS), which is the NCSC's preferred option.
Restrict supported ciphers on both ends of the communication, so that only strong ciphers may be used. Take additional steps to maximise the security of the data connection, such as using certificate pinning to ensure the application connects to a host with a known, trusted certificate.
Never send sensitive data over an insecure or unencrypted connection, and where possible non-sensitive data should also be sent over a secure connection.
Alert the user if any suspicious attributes are detected that indicate the secure communication channel is under attack. In this case, the connection should be denied until a verified secure channel is available.

Session handling

Session handling requires appropriate controls to be placed on the backend server to which the application connects.
Ensure the backend server treats the application (and its user) as untrusted, until they can provide appropriate authentication.
Ensure that sessions timeout periodically and require the user or application to repeat the authentication process.

Application hardening

Modern platforms typically avoid compiling applications to native code, instead preferring to use an intermediate language running in a container. However, it is possible, and sometimes necessary, to include native code components. As a developer you should be aware of the security differences between native and managed code. Principally, native code does not provide the same protections against memory mismanagement issues, such as buffer overflows and use-after-freevulnerabilities.

Stack protection

Compile native code portions of the application to take advantage of any protection mechanisms that are available on the platform.
Enable features such as Address Space Layout Randomisation (ASLR) and Stack Canaries during compilation in order to make the application more difficult to exploit. However, these should only be used to increase the effort needed to exploit vulnerabilities, and should not be solely relied upon to prevent exploitation.

Code obfuscation

You can take steps to make your applications more difficult to reverse engineer, but it's important that applications remain secure even when the entire system is understood by an attacker. As such, obfuscation techniques should only be considered to prevent the reverse engineering of technologies to safeguard (for example) intellectual property, and not to provide a robust security system. Even so, you can use obfuscation of both native and managed code to make reverse engineering attempts more difficult. This is also likely to increase the effort required for attackers to understand how to attack and break the application’s security model.

Jailbreak and root detection

Jailbroken or rooted devices are a threat to sensitive data they contain. As a method of hardening the application, consider implementing checks to detect if the device has been compromised. Detection will always be subject to circumvention by a determined attacker, however tests for common jailbreak and rooting methods allow for the application to take appropriate steps, such as alerting the user, or preventing the device from processing sensitive information.

Third party applications

You might be considering deploying third party applications on the same device as applications that handle sensitive data. The primary concerns here are:

protecting the enterprise network infrastructure from attack via the third party applications
preventing data from leaking from a sensitive datastore into a third party application

Modern platforms have built-in support for segregation of applications and users, which you should use wherever possible.

As the behaviour of third party applications cannot normally be modified, protection has to be provided elsewhere, via network protections and appropriate use of data-stores. Where possible, the developers of any third party applications should be approached in order to gain a deeper understanding of their product.

Applications that are likely to:

be sources of data leaks
track user movements
interfere with other applications

- should not be installed. If software must be used despite security concerns that cannot be mitigated with technical controls, users should be given training on how best to manage the risk.

PAGE 3 OF 16

Android application development

Recommendations for the secure development, procurement and deployment of Android applications.

This guidance contains recommendations for the secure development, procurement and deployment of Android applications. Please familiarise yourself with the generic application development guidance before continuing.

Note that this guidance also refers to concepts described in the Android Security Centre and the NCSC End User Devices Security Guidance. We recommend you familiarise yourself with these documents before reading this guidance.
A general guide to secure Android programming can be found on the Android developer web site.

PAGE 4 OF 16

Secure Android application development

How to securely develop an Android application, including how to store, handle or process sensitive data and the recommended network configuration.

1.1 Datastore hardening

Android, by default, provides each application on a device with access to a private directory to store its files. This protection is implemented using Linux user and group permissions. The security model is further enforced by applying Security-Enhanced Linux mandatory access control policies and leveraging a seccomp system call filter.

Android, as of version 7.0, on devices with file-based encryption (FBE), provides two storage locations on devices with FBE and Direct Boot. On FBE-enabled devices, developers should only store sensitive data in the Credential Encrypted (CE) storage.

Applications are able to access other areas of the device, such as contacts and SMS, by requesting permission from the user at runtime. The user can choose to permit the application access to areas such as the device’s calendar and phonebook, as well as features such as making phone calls or reading the current location. Once permitted, the application may use these features without further interaction from the user.

Despite protection offered by Android's sandboxing, it remains the responsibility of the application to store its data securely and to not undermine any protections that are in place by (for instance):

writing data to publicly readable locations such as the external storage
handling intents that can be called by any other application on the same device
creating files with world readable/writable permissions

Remember that a process running on the device with sufficient permissions, will always be able to read and write any data in any application’s sandbox. We strongly recommended that applications holding sensitive data should build upon the sandbox with more secure functionality by (for example) leveraging the hardware-backed KeyStore.

Ultimately, it is not possible to guarantee the security of data on a device. You should assume that if a user continues to use a device after it has been compromised, the malware will be able to access the data. Android provides an API called SafetyNet for assessing the health and safety of the device. This API examines both hardware and software information about the device, to help determine if it has been tampered with or otherwise modified. We recommend that application developers use the API, then send the signed SafetyNet API results to their own servers to be validated, rather than on the device. SafetyNet should be used as a means to gain confidence about the integrity of the device, but it is not guaranteed to detect a compromise.

1.2 Network protection

The diagram below, taken from the EUD Security Guidance for Android, illustrates the recommended network configuration for Android devices which handle sensitive information. In summary, a VPN is used to bring device traffic back to the enterprise. Access to internal services is brokered through a reverse proxy server, which protects the internal network from attack.

To prevent the application from accessing sensitive internal resources, it is important that the reverse proxy server authenticates any requests from devices. This means that applications on the device which are trusted to access sensitive data must provide authentication with each request so that the reverse proxy can validate the request. Stored credentials must be private to only the trusted applications accessing those resources.

Internet requests from the application should be routed via the standard corporate internet gateway, to permit traffic inspection.

1.3 Secure application development

The following section contains recommendations that an Android application should conform to in order to store, handle or process sensitive data. Many of these recommendations are general good-practice behaviours for applications on Android. A number of documented code snippets and examples are available on the Android developer portal.

Secure data storage

In order to store sensitive data in a secure manner, Android applications should conform to the following:

Applications should minimise the amount of data stored on the device. When needed, data should be retrieved from the server over a secure connection, and erased when it is no longer required.
Sensitive information, if required, should only be stored in the hardware-backed KeyStore.
The device’s external storage (for example the SD card) should not be used by the application to store sensitive data.

Server-side controls

Applications which store credentials should have robust server-side control procedures in place to revoke the credential, should the device or data be compromised.

Secure data transmission

In order to transmit sensitive data securely, Android applications should conform to the following:

All off-device communications handling sensitive data should take place over a mutually-authenticated, cryptographically protected, connection.
For TLS connections, the application should perform certificate pinning to a known endpoint. This process should leverage the Network Security Configuration. For more information refer to the NCSC’s TLS documentation.
Certificates used by the application should be stored on the device using the Android KeyStore provider.

Note that at present there is no API on Android to check the status of the VPN. To securely check the status of the VPN, the internal service with which the application is communicating must be authenticated. The recommended way of performing this authentication is TLS with a pinned certificate. If mutual authentication is required to the internal service, mutual TLS with pinned certificates should be used.

Application security

To hinder the exploitation of any potential memory corruption vulnerabilities, the following recommendations should be followed:

The application should be compiled using the latest supported compiler security flags.
The application should not be compiled with the debug flag enabled.
The application should not use any private APIs.
The application should be compiled in release mode with all debug information stripped from the binaries.
If Android Studio is used, it should be configured to shrink and optimise Java code.

Security recommendations

The behaviours listed below can increase the overall security of an application.

Any data that is deemed necessary to store on the device should be encrypted either with keys that are not stored on the device, or that are stored in the Android KeyStore. Furthermore, key attestation should be used when hardware-backed key storage is available.
Where possible, applications should sanitise in-memory buffers of sensitive data after use (if the data is no longer required for operation).
Applications that require authentication on application launch should also request this authentication credential when returning back to the foreground after previously being backgrounded by a user, allowing for a small grace period.
As the standard Android clipboard is shared between all applications on the device, do not not use it when accessing sensitive data. A private clipboard can be implemented if required by the application.
The application should disable both manual and automatic screenshots within activities that display sensitive data by setting secure flags of the window within the application.
Applications that use a shared UID will share the same sandbox. This means that if one application was compromised, all data in any application with a shared UID would also be compromised. Developers should share functionality between applications using intents, restricted by permissions.
Intents created for IPC between trusted applications should use signature permissions to restrict access by other applications on the device.
Applications that use Web Views should limit the features and capabilities to the minimum functionality required.The application should ensure that debugging output has been removed and sensitive information prevented from appearing within the device log files.

JavaScript and local file access should be disabled unless specifically required.
Caching should be disabled to prevent unnecessary exposure of sensitive data.

The application should ensure that debugging output has been removed and sensitive information prevented from appearing within the device log files.

Allmänt · ‽IT · ∴ · interrobangit · § · §IT

Dela · Kommentera

:

Kommentera

Av Svenn Dybvik - 23 april 2023 00:00

https://www.ncsc.gov.uk/collection/application-development/android-application-development/questions-for-android-application-developers

PAGE 5 OF 16

Questions for application developers

When procuring an application built by a third party, ask developers these example questions to get an understanding of the security of their products.

For anyone procuring an application built by a third party, you can ask developers the example questions below. Their answers will help you gain more (or less) confidence about the security of their products.

The most thorough way to assess an application before deploying it would be to conduct a full source code review to ensure it meets the security recommendations and contains no malicious or unwanted functionality. Unfortunately, for the majority of third party applications, this will be infeasible or impossible. However, the responses from the third party should help provide confidence that the application is well written and likely to protect information properly.

2.1 Secure data storage

The following questions will help you establish how confident you can be that an Android application stores sensitive data securely.

https://www.ncsc.gov.uk/collection/application-development/android-application-development/questions-for-android-application-developers

2.2 Secure data transmission

The following questions will help you gain confidence in how Android applications transmit sensitive data securely:

https://www.ncsc.gov.uk/collection/application-development/android-application-development/questions-for-android-application-developers

2.3 IPC mechanisms

The following questions will help you gain confidence in how Android applications share sensitive data securely.

https://www.ncsc.gov.uk/collection/application-development/android-application-development/questions-for-android-application-developers

2.4 Binary protection

The following questions will help you gain confidence in how Android applications protect their data within a binary.

https://www.ncsc.gov.uk/collection/application-development/android-application-development/questions-for-android-application-developers

2.5 Server side controls

The following questions will help you gain confidence in how Android applications protect their data on the server side.

https://www.ncsc.gov.uk/collection/application-development/android-application-development/questions-for-android-application-developers

2.6 Client side controls

The following questions are will help you gain confidence in how Android applications protect their data on the client side.

https://www.ncsc.gov.uk/collection/application-development/android-application-development/questions-for-android-application-developers

2.7 Other

https://www.ncsc.gov.uk/collection/application-development/android-application-development/questions-for-android-application-developers

PAGE 6 OF 16

Secure deployment of Android applications

This section recommends how to securely deploy the application, should it be from third party organisation or via an in-house application.

3.1 Third party app store applications

Android supports a number of methods to install new third party applications. The following section divides these into two categories, trusted and untrusted:

Untrusted third party applications

Untrusted applications are those that have been produced by developers that your organisation does not have a relationship with. This includes applications hosted by both Google Play and on third party application stores. In these instances you should assume that the third party application may have unwanted functionality. While this functionality may not necessarily be malicious, these applications should be viewed as potential sources of leakage for sensitive data. You should evaluate whether or not an application can run on the device.

Network architecture components such as the reverse proxy can be used to help restrict third party applications from accessing corporate infrastructure. However, these features should be regarded as techniques to help mitigate the potential threat posed by the installation of third-party applications, they cannot guarantee complete protection.

The ideal method of mitigation is to not allow any third party applications to be installed on the device, though in reality this must be taken on a 'per application' basis. Where possible, developers of the application should be consulted in order to understand better the limitations and restrictions of the application. To help your evaluation, you can use the questions given above (feel free to ask more, these represent the minimum you should find out).

Trusted third party applications

You should learn as much as possible about the security posture of an application, so that the risks of deploying it can be understood and managed wherever possible. Your organisation should, ideally, establish a relationship with developers and work with them to understand how their product does (or does not) meet the security posture expected of it.

You should assess third party applications to decide whether the risk of having their code executing on your devices is outweighed by the benefits that the application brings to your organisation. If third party applications are to be permitted on devices with sensitive data, then the following steps should be taken:

Ensure that the applications holding sensitive data do not permit third party application access to the data, for instance making sure that the third party application is not included as one that the user can choose to open sensitive documents with.
Ensure that sensitive data would remain secure if the third party application were compromised. For instance, the data should not be accessible due to it being stored in a world-readable location on the device.

Where a third party application is being considered to manage sensitive data, you may also wish to consider commissioning independent assurance. This is particularly true if the application implements its own protection technologies (such as a VPN or data-at-rest encryption), and does not use the native protections provided by Android. Many enterprise applications feature server side components and when present, these should be considered as part of the wider risk assessment..

Private enterprise application catalogues can be created and managed using MDM solutions, allowing organisations to build a set of accepted third party and in-house applications that can either be installed on to every organisational device, or made available for employees to browse and choose to install manually.

Security considerations

When deploying third party applications, the primary concern for an organisation is determining whether these applications could affect the security of the enterprise network, or access data held in a sensitive datastore.

Malware and application level vulnerabilities are of particular concern when developing secure applications for Android. Secure applications must therefore pay particular attention when protecting data both in storage on a device and in transit, if third party applications are permitted on the same device.

You should also consider the security features of the devices that will host your application. A number of manufacturers offer custom security features to protect corporate data from other applications. If the application will only be used on these devices, then permitting third party applications on the same device may be deemed acceptable.

SECURITY REQUIREMENTS

Best practice when using third party applications is as follows:

Server side components such as a reverse proxy should be used to restrict network enterprise access to trusted applications.
The developers should be contacted in order to better understand the security posture of the application. Use the Questions for Application Developers section as your starting point.
Data should be protected from third party applications by restricting their access to sensitive data and functionality.

3.2 In-house applications

In-house applications are those designed and commissioned by an organisation to fulfil a particular business requirement. The organisation can stipulate the functional and security requirements of the application, and enforce these contractually if the development work is subcontracted.

The intention when securing these applications is to minimise the opportunity for data leakage from these applications and to harden them against physical and network-level attacks. For the purposes of this document, these applications are assumed to access, store, and process sensitive data.

SECURITY CONSIDERATIONS

Regardless of whether the application is developed by an internal development team, or under contract by an external developer, you should ensure that supplied binaries match the version which you were expecting to receive. Applications should then be installed onto managed devices through an MDM server or in-house enterprise application catalogue front-end, to gain the benefits of an application being enterprise managed.

SECURITY REQUIREMENTS

Both in-house and third party applications should be deployed directly to devices through an in-house enterprise application catalogue. This means they can be remotely managed, and kept separate from third party applications installed by the user.

PAGE 7 OF 16

Application wrappers

This section covers the different types of application wrappers, giving descriptions and the security considerations of each.

4.1 Security considerations

A variety of 'application wrapping' technologies exist on the market today. Whilst these technologies ostensibly come in a variety of forms which provide different end-user benefits, on most platforms (including Android) they essentially work in one of three ways.

Category 1: These provide a remote view of an enterprise service, for example a Remote Desktop view of a set of internal applications that are running at a remote location, or an HTML-based web application. Multiple applications may appear to be contained within a single application container, or may live separately in multiple containers to simulate the appearance of multiple native applications. Usually, only temporary cached data and/or a credential is persistent on the device itself.

Category 2: These are added to an application binary after compilation and dynamically modify the behaviour of the running application (for example to run the application within another sandbox and intercept and modify platform API calls) in an attempt to enforce data protection.

Category 3: The source code to the surrogate application is modified to incorporate a Software Development Kit (SDK) provided by the technology vendor. This SDK modifies the behaviour of standard API calls to instead call the SDKs API. The developer of the surrogate application will normally need to be involved in the wrapping process.

4.2 Security requirements

Category 1 technologies are essentially normal platform applications, but which store and process minimal information, deferring processing and storage to a central location. The development requirements for these applications are identical to other native platform applications. Developers should follow the guidelines given above.

Category 2and category 3 wrapping technologies are frequently used to provide enterprise management to applications via the MDM server that the device is managed by. SDKs are integrated into these MDM solutions and can be used to configure settings in the application or to modify its behaviour. For example, the application could be modified to always encrypt all data or not use certain API calls.

On Android, both category 2 and category 3 wrapping technologies require the surrogate developer’s co-operation to wrap the application into a signed package for deployment onto an Android device. As such, normally only custom developed in-house applications, and sometimes trusted third party applications (with co-operation) can use these technologies. As the robustness of these wrapping technologies cannot be asserted in the general case, they should not be used with an untrusted application; they should only be used to modify the behaviour of trusted applications, or for ease of management of the wrapped applications.

In-house applications should be developed specifically against the previously described security recommendations wherever possible. The use of app-wrapping technologies should only be used as a less favourable alternative method of meeting the given security recommendations where natively meeting them is not possible.

Ultimately, it is more challenging to gain confidence in an application whose behaviour has been modified by a category 2 technology. It is difficult to assert that dynamic application wrapping can cover all the possible ways an application may attempt to store, access and modify data. It is also difficult to make any general assertions about how any given wrapped application will behave. As such, the NCSC cannot give any assurances about category 2 technologies or wrapped applications in general, and hence cannot recommend their use as a security barrier at this time.

However, category 3 technologies are essentially an SDK or library which developers use as they would any other library or SDK. In the same way that the NCSC does not assure any standalone cryptographic libraries, we do not provide assurance in SDKs which wrap applications. The developer using the SDK should be confident of its functionality, as they would be with any other library.

PAGE 8 OF 16

Apple iOS application development

Recommendations for the secure development, procurement and deployment of Apple iOS applications.

This guidance contains recommendations for the secure development,procurement and deployment of iOS applications. Please familiarise yourself with the generic application development guidance section before continuing.

Note that this guidance also refers to concepts described in the NCSC End User Devices Security Guidance. We recommend you familiarise yourself with this before reading the guidance below.
A general guide to secure Apple programming can be found in Apple’s security guide.

Regarding data at rest and keychain protection classes, the following terminology will be used:

https://www.ncsc.gov.uk/collection/application-development/apple-ios-application-development

Note that the other keychain classes have a ‘This device only’ counterpart. More information about these protection classes can be found within Apple’s security guide document and API documentation.

Allmänt · ‽IT · ∴ · interrobangit · § · §IT

Dela · Kommentera

:

Kommentera

Av Svenn Dybvik - 16 april 2023 00:00

https://www.ncsc.gov.uk/collection/application-development/apple-ios-application-development/secure-ios-application-development

PAGE 9 OF 16

Secure iOS application development

How to securely develop an iOS application, including how to store, handle or process sensitive data and the recommended network configuration.

1.1 Datastore hardening

By default, third party App Store applications on iOS will be able to ask for access the users’ Calendars, Contacts, Camera, Location, Photos, and Social Networking accounts. On iOS these accesses are prompted on first use in each application, such that the user can accept or decline the permission. You can configure Restrictions settings on the device to prevent this functionality being used. Within an organisation, this is typically configured and deployed using an MDM-based solution. More information about MDM managed devices can be found within NCSC’s end user device guidance.

Nevertheless, there remains the possibility that the user could accept these access permissions and the application could access data in these stores. If there's a risk of an untrusted app accessing this data, then you should not store sensitive information within these datastores. A third party application may be able to store this information more securely than the default stores.

As the potential exists that the device may be compromised, on-device encryption routines cannot be solely relied on to protect sensitive information. Sensitive information should not be stored on a device for longer than it is required. Where sensitive information is stored on the device, even if temporarily, the following steps should be taken:

Sensitive credentials should be sufficiently encrypted before being stored within the keychain using the appropriate keychain class described in section 1.3 below.
The appropriate data protection class should still be used.
Sensitive data stored by the application should be marked with the 'do not backup' attribute to ensure that specified files are not included within an iTunes or iCloud backup.

1.2 Network protection

The diagram below, taken from the NCSC EUD Security Guidance for iOS, illustrates the recommended network configuration for iOS devices which handle sensitive information. In summary, a VPN is used to bring device traffic back to the enterprise. Access to internal services is brokered through a reverse proxy server, which protects the internal network from attack.

To prevent the application from accessing sensitive internal resources, it is important that the reverse proxy server authenticates any requests from devices. This means that applications on the device, which are trusted to access sensitive data, should provide authentication with each request so that the reverse proxy can validate the request. Stored credentials should be private to only the trusted applications accessing those resources.

Internet requests from the application should be routed via the standard corporate Internet gateway, to permit traffic inspection.

1.3 Secure application development recommendations

The following section contains recommendations that an iOS application should conform to in order to store, handle or process sensitive data. Many of these recommendations are general good-practice behaviours for applications on iOS, and a number of documented code snippets and examples are available on Apple’s developer portal.

Secure data storage

In order to store sensitive data in a secure manner, iOS applications should conform to the following:

Applications should use the iOS Keychain APIs to store credentials.
Applications should use the iOS Data Protection API to store sensitive file system data.
Applications should store as much data as possible using data protection classes A and B.
Private keys should be marked as non-migratory.
Where a credential is required to authenticate to a remote service that provides access to sensitive data, applications must store this credential in Class A or C keychain protection classes, or prompt for the credential on application launch.
The kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly attribute could also be used to further harden local credential storage to prevent any synchronisation with the iCloud keychain. This acts the same as kSecAttrAccessibleWhenUnlocked. However, it is only available when devices have a passcode set and is protected via hardware-backed storage mechanisms.
Developers should be careful when storing information in the cloud. iCloud or other Internet-based storage solutions should not be used to store sensitive information (e.g. credentials). The application must work as expected if iCloud is disabled on the device.
Certain keychain APIs can be used to further constrain specific keychain items. To only allow access for Touch ID only, use kSecAccessControlTouchIDCurrentSet. A similar effect can be achieved using the secure enclave hardware-based key manager (kSecAttrTokenIDSecureEnclave). These attributes should be investigated to ensure the appropriate level of protection is implemented during development of a feature. More information about the secure enclave can be found within the API documentation.
On iOS version 9 and later, it is also possible to prevent a physical attacker from enrolling their own fingerprint on the device. This can be performed by reading the evaluatedPolicyDomainState variable to determine if TouchID enrolment changes have occurred since last usage.
We recommend that the application performs a wipe of its keychain data on first install (not upgrade). This can prevent keychain data being reused if the device is, for example, sold at a later stage and a full device wipe has not been performed.
Mask off all sensitive data on screen when the application receives notifications that will enter the background state using applicationWillResignActive and applicationDidEnterBackground. This is to ensure that the screenshot taken of the application does not contain sensitive information.
Network communication can also be cached within certain databases within the application sandbox. Ensure any network-level caching is not performed when sensitive data is being retrieved from the server side. Certain iOS APIs perform caching of network traffic (including plaintext data sent via HTTPS) on the device. If an attacker is able to gain access to the contents of the sandbox, they may be able to recover this data. Therefore, caching related APIs should be reviewed to ensure that sensitive data is not stored. More information can be found within Apple’s cache policy documentation.

Server side controls

Applications which store credentials must have robust server-side control procedures in place in order to revoke credentials should the device or data be compromised.

Pasteboard and debugging data

The application must manage the pasteboard effectively by doing one (or more) of the following:

Clear the pasteboard when the application exits or loses focus (crashes may still result in data leakage).
Implement a private pasteboard within your application - do not use the system pasteboard.
Encrypt the pasteboard with a key stored in the Developer’s keychain. This also allows pasting between the same developer’s applications.
Exclude sensitive information from the Universal Clipboard (Handoff Feature). This can be performed by using the setItems(_:options:) method with the localOnly option within the UIPasteBoard class.

The application must ensure that debugging output has been removed and sensitive information prevented from appearing within the device log files.

Logging APIs such as ‘NSLog’, ‘printf’, ‘NSAssert’, etc. should be reviewed and removed from production builds if sensitive information is being logged using these APIs.
The application should detect and notify a user when screen capture is performed on iOS 11 and take appropriate action. For example, the application could display a warning and/or exit to prevent screen capture of sensitive data. More information about this feature can be found within the API documentation.

Secure data transmission

In order to transmit sensitive data securely, iOS applications should conform to the following:

All off-device communications must take place over a mutually-authenticated, cryptographically-protected connection. For example:The application must not allow its sensitive data to be opened in other applications on the device (e.g. through Open In) unless that application is on an appropriate enterprise-managed allow list.
- the assured IPsec VPN to the corporate network
- Secure Chorus for secure real-time media streaming such as secure voice
- Transport Layer Security (TLS) with certificate pinning to a known endpoint to a service within the corporate network; more information on TLS can be found within NCSC’s TLS documentation
Any security-critical settings (such as server addresses and certificates) must be defined at build time or be enterprise-managed. The user must not be able to alter these settings.
If cloud services, such as iCloud, are used by the app to store information, this should be protected using the appropriate encryption mechanisms both from a network transmission perspective and data storage perspective.
Applications should make use of App Transport Security (ATS) and should not disable this feature or add domains to the exception allow list. Applications should aim to keep perfect forward secrecy (PFS) enabled and not reduce the minimum TLS version supported.
Ensure that kSecAttrSynchronizable is not set for security-sensitive keychain items (as they will be included in an iCloud keychain backup, if this functionality is enabled).

Note that at present there is no API on iOS to check the status of the VPN. To securely check the status of the VPN, the internal service with which the application is communicating must be authenticated. The recommended way of performing this authentication is TLS with a pinned certificate. If mutual authentication is required to the internal service, mutual TLS with pinned certificates should be used.

Application security

To hinder the exploitation of any potential memory corruption vulnerabilities, the following recommendations should be followed:

The application should be compiled using the latest supported security flags.
The binary should be compiled with the Process Independent Executable (PIE) flag set.
The application should make use of Automatic Reference Counting (ARC) – which is enabled by default.
The application should not use private APIs.

Client side security

The following recommendations should be followed to improve the security of the client:

Secure coding practices should be followed to protect against input injection attacks. More information can be found in Apple’s secure coding guide.
If the application uses Web Views (UIWebView, WKWebView or FSafariViewController) it should disable features which are not required by content loaded into the WebView (for example JavaScript or local file access). This will lead to a reduction in attack surface and help protect this area of the application.
If content is being loaded locally into a Web View, users should be prevented from changing the filename or path which is loaded and they should not be able to edit the loaded file.

Security requirements

The following list includes some other behaviours which can increase the overall security of an application.

Applications should store as much data as possible in data protection classes A and B (as described at the top of this page).
Applications should sanitise in-memory buffers after use, where possible, if the data is no longer required for operation (for example a temporary password or PIN buffer).
Applications should not upgrade the storage class of an existing file from Class D to a higher class. Instead, create a new file and copy the data across before deleting the original file. This ensures that the file is wrapped with a new key that may not be forensically recovered from Class D analysis.
Applications should minimise the amount of data stored on the device. Retrieve data from the server when needed, over a secure connection, and erase it when it is no longer required.
Applications that require authentication when launched should also request this authentication credential when returning back into the foreground after previously being backgrounded by a user, allowing for a small grace period.

PAGE 10 OF 16

Questions for application developers

2.1 Secure data storage

The following questions will help you gain confidence that an iOS application stores sensitive data securely:

https://www.ncsc.gov.uk/collection/application-development/apple-ios-application-development/questions-for-application-developers

2.2 Secure data transmission

The following questions will help you gain confidence that an iOS application transmits sensitive data securely:

https://www.ncsc.gov.uk/collection/application-development/apple-ios-application-development/questions-for-application-developers

2.3 IPC mechanisms

The following questions will help you gain confidence that an iOS application shares sensitive data securely:

https://www.ncsc.gov.uk/collection/application-development/apple-ios-application-development/questions-for-application-developers

2.4 Binary protection

The following questions will help you gain confidence that an iOS application protects its data within a binary:

https://www.ncsc.gov.uk/collection/application-development/apple-ios-application-development/questions-for-application-developers

2.5 Server side controls

The following questions will help you gain confidence that an iOS application protects its data on the server side:

https://www.ncsc.gov.uk/collection/application-development/apple-ios-application-development/questions-for-application-developers

2.6 Client side controls

The following questions will help you gain confidence that an iOS application protects its data on the client side:

https://www.ncsc.gov.uk/collection/application-development/apple-ios-application-development/questions-for-application-developers

2.7 Other

These additional questions will help you gain confidence in how an iOS application protects itself.

https://www.ncsc.gov.uk/collection/application-development/apple-ios-application-development/questions-for-application-developers

PAGE 11 OF 16

Secure deployment of iOS applications

This section recommends how to securely deploy the application, should it be from third party organisation or via an in-house application.

3.1 Third party app store applications

iOS supports a number of methods to install new third party applications. The following section divides these into two categories, trusted and untrusted.

Untrusted third party applications

Untrusted applications are those that have been produced by developers that your organisation does not have a relationship with. This includes applications hosted on the Apple App Store. Untrusted applications should be restricted from handling sensitive material. You should assume that a proportion of third party applications will have unwanted functionality. While this functionality may not necessarily be malicious, these applications should be viewed as potential sources of leakage for sensitive data. You should evaluate whether or not an application can run on the device.

Operating system features can be used to help restrict third party applications from corporate infrastructure. Although these features should be regarded as techniques to help mitigate the potential threat posed by the installation of third party applications, they cannot guarantee complete protection.

The ideal method of mitigation is to not allow any third party applications to be installed on the device, though in reality this decision must be taken on a per application basis. Where possible, consult the developers of the application to understand better its limitations and restrictions. To help your evaluation, you can use the questions given above in the Questions for application developers section (feel free to ask more, these represent the minimum you should find out).

Trusted third party applications

A trusted third party application is an application that has not been developed in-house, but where the risk of trusting the application has been accepted. This should not result in complete trust in the application. Steps should be taken to minimise the threat and impact an application may have if it turns out to be malicious, or compromised.

Unless specifically designed to handle sensitive material, a third party application should never have access to it. Native operating system features, such as Open In Management, should be used to restrict sensitive access only to applications that have been approved. A third party PDF reader installed from Apple’s App Store, for example, should never be allowed to access your corporate infrastructure.

You should learn as much as possible about the security posture of an application, so that the risks of deploying it can be understood and managed wherever possible. Organisations should ideally establish a relationship with the developers of these products and work with them to understand how their product does (or does not) meet its expected security posture.

Where a third party application is being considered to manage sensitive data, you may also wish to consider commissioning independent assurance. This is particularly true if the application implements its own protection technologies (such as a VPN or data-at-rest encryption), and does not use the native protections provided by iOS. Many enterprise applications feature server side components and when present, these should be considered as part of the wider risk assessment.

Security considerations

Third party applications may pose a threat to your organisation. Though Apple screens applications submitted to the App Store, this does not ensure that they are free of malware. Malicious applications may seek to gain access to sensitive information, or attempt to access your organisation’s network. Precautions should be taken in order to mitigate these threats.

In order to prevent sensitive information being leaked to a third party application, it should be stored and transmitted securely. The data should be stored on the device using Class A data storage. When in transit, encrypted protocols should be used.

Third party applications should be excluded from accessing your organisation’s network. This can be achieved by only allowing trusted applications to access the VPN to your organisation’s network, using the Per App VPN feature.

Approaching the developers of an application will help gain an insight into its construction. An application should not be installed if it is likely to leak data, interfere with other applications or track the movements of a user.

Security requirements

Best practice when using third party applications is as follows:

Server side components such as a reverse proxy should be used to restrict network enterprise access to trusted applications.
The developers should be contacted in order to better understand the security posture of the application. Use the Questions for Application Developers section as your starting point.
Data should be protected from third party applications by making appropriate use of the keychain.
Open-in Management should be used to ensure certain file types can only be accessed by approved applications. This will help prevent applications that were not designed for handling sensitive documents from doing so.

3.2 In-house applications

In-house applications are those designed and commissioned by an organisation to fulfil a particular business requirement. The organisation can stipulate the functionality and security requirements of the application, and can enforce these contractually if the development work is subcontracted.

The intention when securing these applications is to minimise the opportunity for data leakage from these applications, and to harden them against physical and network-level attacks. For the purposes of this document, these applications are assumed to access, store, and process sensitive data.

Security considerations

Regardless of whether the application is developed by an internal development team, or under contract by an external developer, you should ensure that supplied binaries match the version which you were expecting to receive if supplied via business-to-business or the App Store. Either way, applications should then be installed onto managed devices through an MDM server or enterprise app catalogue front-end, to gain the benefits of the app being enterprise-managed.

Security requirements

Both in-house and third party App Store applications should be deployed directly to devices through an enterprise app catalogue. This means they will be marked as managed applications which will not be subject to iCloud backup routines.

Third party applications listed on an enterprise app catalogue may link through to the public App Store. In order for a user to install these applications, the public App Store must be enabled, meaning that any application from the public App Store can be installed. To manage this risk, policies and procedures should be put in place to audit devices, ensuring any unpermitted applications are not installed.

PAGE 12 OF 16

Applications wrappers

This section covers the different types of application wrappers, giving descriptions and the security considerations of each.

4. Application wrappers

This section covers the different types of application wrappers, giving descriptions and the security considerations of each.

4.1 Security considerations

A variety of 'application wrapping' technologies exist on the market today. Whilst these technologies ostensibly come in a variety of forms, each providing different end-user benefits, on most platforms (including iOS) they essentially work in one of three ways:

Category 1: These provide a remote view of an enterprise service. For example, a Remote Desktop view of a set of internal applications that are running at a remote location, or a HTML-based web application. Multiple applications may appear to be contained within a single application container, or may live separately in multiple containers to simulate the appearance of multiple native applications. Usually only temporary cached data and/or a credential is persistent on the device itself.

Category 3: The source code to the surrogate application is modified to incorporate a Software Development Kit (SDK) provided by the technology vendor. This SDK modifies the behaviour of standard API calls to instead call the SDK's API. The developer of the surrogate application will normally need to be involved in the wrapping process.

4.2 Security requirements

Category 1 technologies are essentially normal platform applications but which store and process minimal information, rather than deferring processing and storage to a central location. The development requirements for these applications are identical to other native platform applications. Developers should follow the guidelines given above.

Category 2 and 3 wrapping technologies are frequently used to provide enterprise management to applications via the MDM that the device is managed by. SDKs are integrated into these MDM solutions and can be used to configure settings in the application or to modify the behaviour of the application. For example, the application could be modified to always encrypt data or not use certain API calls.

On iOS, both category 2 and category 3 wrapping technologies require the surrogate developer’s co-operation to wrap the application into a signed package for deployment onto an iOS device. As such, normally only custom-developed in-house applications, and sometimes B2B applications (with co-operation) can use these technologies.

As the robustness of these wrapping technologies cannot be asserted in the general case, they should not be used with an untrusted application; they should only be used to modify the behaviour of trusted applications, or for ease of management of the wrapped application. Preferably, in-house applications should be developed specifically against the previously described security recommendations wherever possible. The use of app-wrapping technologies should be seen as a less favourable alternative method of meeting the above security recommendations, where natively meeting them is not possible.

Allmänt · ‽IT · ∴ · interrobangit · § · §IT

Dela · Kommentera

:

Kommentera

Av Svenn Dybvik - 9 april 2023 00:00

https://www.ncsc.gov.uk/collection/application-development/windows-application-development

PAGE 13 OF 16

Windows application development

Recommendations for the secure development, procurement and deployment of Windows applications.

This guidance contains recommendations for the secure development, procurement and deployment of Windows applications. Please familiarise yourself with the Generic application development section before continuing.

Note that this this guidance also refers to concepts described in the Windows Dev Center documentation and the NCSC End User Devices Security Guidance. We recommend you familiarise yourself with these documents before reading this guidance.

PAGE 14 OF 16

Secure Windows application development

How to securely develop a Windows application, including how to store, handle or process sensitive data and the recommended network configuration.

1.1 Datastore hardening

Universal Windows Platform (UWP) applications run in a container, meaning data storage is achieved in a sandboxed environment with its own file system and registry. Additionally, contained applications have restricted access to files on the host system or to data stored by other applications. Application developers do not need to implement anything to take advantage of this secure storage capability.

In cases where it is necessary to share data, UWP provides secure functionality for the following:

reading specific files on the host operating system as selected by the user
data sharing between applications
data storage for the same application across multiple Windows users

Developers should utilise the platform’s native features for those purposes.

Note that while UWP implements the principle of least privilege and ensures its applications cannot access external resources directly, applications with administrator privileges will still be able to read and write data to a UWP application.

1.2 Network protection

The diagram below, taken from the Windows 10 security guidance, illustrates the recommended network configuration for UWP devices handling sensitive data. In summary, a VPN is used to bring device traffic back to the enterprise. Access to internal services is brokered through a reverse proxy server which protects the internal network from attack.

1.3 Authentication

If sensitive data is handled by the application, two-factor authentication should be required when the user logs in. You should integrate Windows Hello into UWP applications to achieve this. Windows Hello provides a biometric system built in to the operating system, and utilises the device’s Trusted Platform Module (TPM) chip for private key generation and storage (if available). This is a recommended option for key management as the TPM protects against several known attacks. Windows Hello can also require a PIN, which is backed by a TPM, if the organisation does not choose to use biometrics.

The Windows Hello two-factor authentication mechanism provides an alternative to smartcards. However, if Windows Hello is unavailable, smartcards can still be used to provide an additional layer of security.

If an application requires user authentication on launch, you should also implement additional checks for when the application has been backgrounded, or its use has been suspended for a length of time. This is necessary to ensure that the current user is still the authenticated user that launched the application. Where two-factor authentication has in place for the session, it would not be user-friendly to require additional two-factor authentication each time the user returns.

For authentication provided by an online identity provider, Single Sign-On (SSO) authentication should be enabled with the use of the Web Authentication Broker APIs native to UWP.

1.4 Secure data storage

Data-at-rest should be protected with use of the encryption and hashing APIs provided by UWP:

The SymmetricKeyAlgorithmProvider and AsymmetricKeyAlgorithmProvider classes should be used to implement encryption.
The CryptographicEngine class provides encryption, decryption, digital signing and signature verification capabilities.
The Security.Cryptography.DataProtection.DataProtectio nProvider class should be used to encrypt and decrypt stored local data.

UWP provides a range of functionality with built-in support for use of a device’s Trusted Platform Module (TPM), which protects against a range of attacks. Data protected by a TPM is very difficult for an attacker to access. The following TPM based functionality can be used to store data securely:

Platform Crypto Provider gives access to robust cryptography schemes, including those that are backed by the TPM. It can be used to securely store data on the device.
Windows Hello has integrated TPM support and can be used to authenticate and validate users for access to sensitive datastores.

Cryptographic keys and sensitive data should not be stored on the device unless they are stored using a TPM via a UWP feature such as those listed above.

When storing credentials, the Credential Locker feature should be used as it prevents other UWP applications from accessing them. Note that non-UWP applications and elevated users are able to access credentials within the Credential Locker, so for increased protection they could be encrypted before being stored. Credential Locker documentation details the following best practices for its use:

only use the credential locker for passwords and not for data blobs
never store credentials in plain-text using app data or roaming settings
only save passwords in the credential locker if the user has:
a) successfully signed in
b) opted to save passwords

1.5 Server-side controls

Applications storing credentials should have robust server-side control procedures in place to revoke credentials or data stored on the device if it's compromised. If credentials are stored using Credential Locker, they can be deleted from all connected devices by using the PasswordVault.Remove functionality.

1.6 Secure data transmission

In order to transmit sensitive data securely, Windows applications should conform to the following:

For TLS connections, certificate pinning to known organisation services should be enforced.
Encrypt any Websocket connections using the wss: URI scheme.
All HTTP or HTTPS connections should use the Web.Http API.
Note that because UWP applications run in a contained environment, issuer certificates to be used for validation are stored in an isolated cache within the container; as a result, you do not need to do anything to store issuer certificates securely.

1.7 Application security

In order to prevent potential memory corruption vulnerabilities and protect against reverse engineering, Windows applications should conform to the following:

The application should be compiled using the latest supported security flags.
The application should be compiled in release mode with all debug information stripped from the binaries.
When applications are updated, the new version should target the latest SDK version.

1.8 General security recommendations

The following additional behaviours can increase the overall security of an application:

Applications should minimise the amount of sensitive data stored on the device, retrieving data from the server when needed over a secure connection, and erase it when it is no longer required.
Applications that require authentication on application launch should also request this authentication credential when returning back into the foreground after previously being backgrounded by a user allowing for a small grace period.

PAGE 15 OF 16

Questions for application developers

2.1 Secure data storage

The following questions will help you gain confidence that a UWP application stores sensitive data in a secure manner:

https://www.ncsc.gov.uk/collection/application-development/windows-application-development/questions-for-application-developers

2.2 Secure data transmission

The following question will help you gain confidence that a UWP application transmits sensitive data securely:

https://www.ncsc.gov.uk/collection/application-development/windows-application-development/questions-for-application-developers

2.3 IPC mechanisms

The following question will help you gain confidence that a UWP application shares sensitive data securely:

https://www.ncsc.gov.uk/collection/application-development/windows-application-development/questions-for-application-developers

2.4 Binary protection

The following questions will help you gain confidence that a UWP application protects its data within a binary:

https://www.ncsc.gov.uk/collection/application-development/windows-application-development/questions-for-application-developers

2.5 Server side controls

The following questions will help you gain confidence that a UWP application protects its data on the server side:

https://www.ncsc.gov.uk/collection/application-development/windows-application-development/questions-for-application-developers

PAGE 16 OF 16

Secure deployment of Windows application

This section recommends how to securely deploy the application, should it be from third party organisation or via an in-house application.

3.1 Third party Windows Store applications

Windows supports a number of methods to install new third party applications. The following section divides such applications into two types: untrusted and trusted.

Untrusted third party applications

Untrusted applications are those that have been produced by developers with whom the organisation does not have an existing relationship. This includes applications hosted by both Windows Store and on third party application stores. In these instances you should assume that the third party application may have unwanted functionality, either due to weaknesses in its design, or deliberately malicious code. The Windows Store does check apps for known malware during the certification process but this should not be relied upon by itself. Untrusted third party applications should therefore never be granted access to sensitive data, and should be assessed before inclusion in your organisation’s private enterprise application catalogue.

The Windows Store indicates which app permissions are required by the application. These should be reviewed carefully to ensure they are appropriate and do not provide the application with unnecessary or unmanaged access to sensitive data.

Network architecture components such as the reverse proxy can be used to help restrict third party applications from accessing corporate infrastructure. Although such features should be regarded as techniques to help mitigate the potential threat posed by the installation of third party applications, they cannot guarantee complete protection.

The ideal method of mitigation is to not allow any third party applications to be installed on the device, though in reality this must be taken on a 'per application' basis. Where possible, developers of the application should be consulted in order to understand better the limitations and restrictions of the application. To help your evaluation, you can use the Questions for application developers section (feel free to ask more, these represent the minimum you should find out).

Trusted third party applications

You are encouraged to learn as much as possible about the security posture of an application, so the risks of deploying it can be understood and managed wherever possible. Your organisation should ideally establish a relationship with the developers of these products and work with them to understand how their product does, or does not, meet the security posture expected.

Trusted applications have been assessed as posing an acceptable amount of risk to the organisation. This should, however, not result in complete trust of the application and steps should be taken to mitigate relevant risks and impacts. A third party application should never have access to sensitive data unless designed and accredited to do so. For those applications deemed to be trusted, their access to data should be restricted and the principle of least privilege should be applied. If devices are managed, restrictions should be applied with use of native operating system features such as Windows Information Protection (WIP), which defines the third party applications that can access enterprise protected files, Virtual Private Networks (VPN) and enterprise data on the clipboard or through a share contract.

Where a third party application is being considered to handle sensitive data, organisations may also wish to consider commissioning independent assurance. This is particularly recommended if the application implements its own protection technologies (such as a VPN or data-at-rest encryption) and does not use the native protections provided by UWP.

Many enterprise applications feature server side components, which should be considered as part of the wider risk assessment.

Security considerations

When deploying third party applications, the primary concern for an organisation is whether applications could affect the security of the enterprise network, or access data held in a sensitive datastore.

UWP applications must pass a certification process before being published to the Windows Store, which includes checks for known viruses and malware. However, this should not be taken as an indication that the application poses no threat to the organisation and additional threat mitigation activities should be undertaken. Specifically, this involves taking the recommended steps to protect both data-at-rest and data-in-transit while third party applications are permitted on the device.

You should also consider security features of the devices that will host their applications. A number of manufacturers offer custom security features to protect corporate data from other applications. If the application will only be used on these devices, permitting third party applications on the same devices may be deemed acceptable.

Security requirements

Best practice when using third party applications is as follows:

Server side components such as a reverse proxy should be used to restrict enterprise network access to trusted applications.
The developers should be contacted in order to better understand the security posture of the application. Use the Questions for Application Developers section as your starting point.
Data should be protected from third party applications by restricting the application’s access to sensitive data and functionality.

3.2 In-house Windows store applications

In-house applications are those applications which are designed and commissioned by an organisation to fulfil a particular business requirement. The organisation can stipulate the functionality and security requirements of the application, and can enforce these contractually if the development work is subcontracted. For the purposes of this document, these applications are assumed to access, store, and process sensitive data. The intention when securing these applications is to minimise the opportunity for data leakage, and to harden them against physical and network-level attacks.

The following best practice guidelines should be followed when developing applications for use internally:

Consider security concerns throughout the product lifecycle, including the design, development, and ongoing support stages.
Ensure that developers and product owners follow the NCSC secure development and deployment guidance.
Ask the questions listed in the Questions for application developers section.
Ensure that contracted developers deliver source code for the final product

3.3 General security advice

Microsoft provide a selection of technologies that can be used to assist the secure deployment of applications for Windows. UWP applications can be deployed to any Windows device through the Windows Store. Non-UWP applications can be packaged with Desktop Bridge for Windows Store deployment on systems running Windows 10 Anniversary edition or later. Desktop Bridge brings the advantages of publishing applications using a store, such as automatically deploying updates, but does not bring the security or containerisation advantages offered by UWP.

When deploying UWP applications from third parties, review whether it is a native UWP application or one provided by Desktop Bridge. In most cases, applications with the 'Uses all system resources' permission are Desktop Bridge applications.

Managed deployment

Where possible, applications should be provided to users as part of a managed Windows domain or MDM service, in an environment protected by other security controls such as restricted user accounts and AppLocker.

As an alternative to the Windows Store, application deployment can be controlled on managed devices through enterprise software management solutions such as SCCM. These solutions can be used together to control access to the software and ensure that users are always running the latest version of the UWP application.

Unmanaged deployment

Deployment to unmanaged devices introduces some risk, as it reduces the complexity of attack needed to compromise the software. In this scenario, the following guidelines should be considered:

Minimise storage of sensitive data on the device.
In a client-server model, input from the software should not be trusted by the server unless further authentication (such as described in the Secure Windows Application Development – Authentication section) is supplied to verify and authenticate an actual user.
Obfuscation and similar technologies could be used to increase the effort required to reverse-engineer the software. However, obfuscation should be considered only for this purpose, and should not be relied upon to provide complete protection.

https://www.ncsc.gov.uk/collection/developers-collection

Secure development and deployment guidance

8 Principles to help you improve and evaluate your development practices, and those of your suppliers

Introduction

Having a secure approach to development has never been so important.

The way we build software and systems is rapidly evolving, becoming more and more automated and integrated. Today, developers can define an entire system architecture in code and tie it to tooling which will automate both testing and deployment.

Thanks in large part to the arrival of cloud computing and 'infrastructure as code', systems of almost any size and complexity can be called into life, changed or terminated without leaving the desktop. On top of these new capabilities a process of quick and regular deployments has evolved. Often referred to as Continuous Delivery, this iterative approach is powerful, flexible and efficient.

But, these strengths bring with them a new set of risks which your security practices must address. To do so, you will need to consider security as a primary concern throughout the development and deployment process. In fact, development & deployment should be a cornerstone of your risk management and threat modelling approach. If you work in this way, the systems, features and fixes you build are less likely to be undermined by security compromise.

What does this guidance do?

This guidance will help you understand the security implications of modern code development and deployment practices. The principles outlined here are primarily discussed in terms of digital services, but they are sufficiently high level that anyone building software which needs to remain secure will find them useful.

The Continuous Delivery approach to writing code introduces new risks, but it also brings a suite of tools for managing risk in the development process: version control, peer review, automated testing. Proper use of these tools can and should lead to increased security in your development practice. This guidance will help you understand how and where to apply these technologies.

IT systems rarely stand still, they change over time. With that in mind, these principles are not intended to be applied once and forgotten. They should be used to help build an environment which continually evaluates your systems as they evolve.

Who is this guidance for?

The simple answer is everyone involved in software development and procurement. These principles are intended to help secure the entire process of software development, from establishing a security-friendly culture in your organisation, through to implementation and ongoing management. Whether you're securing a digital service or a traditional application, these criteria will help you gauge the security maturity of your own, or a supplier's development team, and the products and services you are producing or procuring.

Using these principles does not guarantee a secure product, but should help you gain confidence that the code you deploy is free from malicious interference and fits with your business risk management strategy. It is also not intended as a list of compliance standards - relevant parts may be pragmatically selected and used at your discretion.

Handling sensitive data

If you're developing a product that handles particularly sensitive information (eg information classified at SECRET or TOP SECRET), you should seek additional specialist advice about the specific threats you need to consider.

Technical capacity

This is not in-depth guidance on how to avoid implementation vulnerabilities in the code you write. These are high level principles, intended to help teams responsible for creating IT systems manage their processes securely. The goal is to establish a set of working practices which foster security but also make code generally more stable and easy to maintain.

Security is continuous

Development teams, technologies and good practices evolve over time, so you should re-visit your assessment periodically for it to remain meaningful.

8 Principles of Secure Development & Deployment

1. Secure development is everyone's concern

Everyone should accept that the security of IT systems is important. Even the most amazing application, delivered on time and to budget, is likely to have security vulnerabilities. Having a culture which values and rewards the detection and mitigation of these vulnerabilities is the most efficient and effective way to manage this 'fact of life'. Everyone building and running a service has a responsibility for security.

2. Keep your security knowledge sharp

Without a practical knowledge and understanding of secure development techniques, the code you produce is unlikely to be capable of withstanding attack. Give your developers and delivery team the time and resources necessary to form a good understanding of defensive code development and the risks to the systems they are building.

3. Produce clean & maintainable code

Complexity is the enemy of security. Code should be developed in line with good practice, so it can be extended and maintained effectively. Clean, well documented code is more efficient and easier to develop. It will also be easier to secure. Third party code libraries or other code dependencies need to be considered in the same light as the code you author.

4. Secure your development environment

If your development environment is insecure, it's difficult to have confidence in the security of the code which comes from it. These environments need to be suitably secure, but should also facilitate and not impede the development process. Fortunately, it is possible to provide a solution that is both secure and usable by developers.

5. Protect your code repository

As a central point from which your code is stored and managed, it's crucial that the repository is sufficiently secured. Loss or compromise of access credentials, or breach of the underlying service may allow attackers to modify your codebase without your knowledge. However, if proper security measures are taken, the benefits of using a code repository service far outweigh the risks.

6. Secure the build and deployment pipeline

There are huge efficiency savings to be had from automating functions such as building code, running tests and deploying reference environments. However, these processes are security critical. Take care to ensure that your build and deployment tooling cannot undermine the integrity of your code, and that key security processes cannot be bypassed before changes are pushed to your customers.

7. Continually test your security

Performing security testing is critical in detecting and fixing security vulnerabilities. However, it should not get in the way of continuous delivery. Automating security testing where possible provides you with easily repeatable, scalable security measures. Your specialist security people can then concentrate on finding subtle and uncommon weaknesses.

8. Plan for security flaws

All code is susceptible to bugs and security vulnerabilities. This is a fact of life. Accept that your code will have exploitable shortcomings and establish a process for capturing and managing them from identification through to the release of a fix. Keep track of your security debt by tracking issues with a register from identification to mitigation.

Allmänt · ‽IT · ∴ · interrobangit · § · §IT

Dela · Kommentera

:

Kommentera

Av Svenn Dybvik - 2 april 2023 00:00

https://www.commoncriteriaportal.org/index.cfm

Common Criteria

The Common Criteria for Information Technology Security Evaluation (CC), and the companion Common Methodology for Information Technology Security Evaluation (CEM) are the technical basis for an international agreement, the Common Criteria Recognition Arrangement (CCRA), which ensures that:

Products can be evaluated by competent and independent licensed laboratories so as to determine the fulfilment of particular security properties, to a certain extent or assurance;
Supporting documents, are used within the Common Criteria certification process to define how the criteria and evaluation methods are applied when certifying specific technologies;
The certification of the security properties of an evaluated product can be issued by a number of Certificate Authorizing Schemes, with this certification being based on the result of their evaluation;
These certificates are recognized by all the signatories of the CCRA.

The CC is the driving force for the widest available mutual recognition of secure IT products. This web portal is available to support the information on the status of the CCRA, the CC and the certification schemes, licensed laboratories, certified products and related information, news and events.

https://owasp.org/www-project-top-ten/

The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.

Globally recognized by developers as the first step towards more secure coding.

Companies should adopt this document and start the process of ensuring that their web applications minimize these risks. Using the OWASP Top 10 is perhaps the most effective first step towards changing the software development culture within your organization into one that produces more secure code.

Top 10 Web Application Security Risks

There are three new categories, four categories with naming and scoping changes, and some consolidation in the Top 10 for 2021.

A01:2021-Broken Access Control moves up from the fifth position; 94% of applications were tested for some form of broken access control. The 34 Common Weakness Enumerations (CWEs) mapped to Broken Access Control had more occurrences in applications than any other category.
A02:2021-Cryptographic Failures shifts up one position to #2, previously known as Sensitive Data Exposure, which was broad symptom rather than a root cause. The renewed focus here is on failures related to cryptography which often leads to sensitive data exposure or system compromise.
A03:2021-Injection slides down to the third position. 94% of the applications were tested for some form of injection, and the 33 CWEs mapped into this category have the second most occurrences in applications. Cross-site Scripting is now part of this category in this edition.
A04:2021-Insecure Design is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to “move left” as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures.
A05:2021-Security Misconfiguration moves up from #6 in the previous edition; 90% of applications were tested for some form of misconfiguration. With more shifts into highly configurable software, it’s not surprising to see this category move up. The former category for XML External Entities (XXE) is now part of this category.
A06:2021-Vulnerable and Outdated Components was previously titled Using Components with Known Vulnerabilities and is #2 in the Top 10 community survey, but also had enough data to make the Top 10 via data analysis. This category moves up from #9 in 2017 and is a known issue that we struggle to test and assess risk. It is the only category not to have any Common Vulnerability and Exposures (CVEs) mapped to the included CWEs, so a default exploit and impact weights of 5.0 are factored into their scores.
A07:2021-Identification and Authentication Failures was previously Broken Authentication and is sliding down from the second position, and now includes CWEs that are more related to identification failures. This category is still an integral part of the Top 10, but the increased availability of standardized frameworks seems to be helping.
A08:2021-Software and Data Integrity Failures is a new category for 2021, focusing on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. One of the highest weighted impacts from Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) data mapped to the 10 CWEs in this category. Insecure Deserialization from 2017 is now a part of this larger category.
A09:2021-Security Logging and Monitoring Failures was previously Insufficient Logging & Monitoring and is added from the industry survey (#3), moving up from #10 previously. This category is expanded to include more types of failures, is challenging to test for, and isn’t well represented in the CVE/CVSS data. However, failures in this category can directly impact visibility, incident alerting, and forensics.
A10:2021-Server-Side Request Forgery is added from the Top 10 community survey (#1). The data shows a relatively low incidence rate with above average testing coverage, along with above-average ratings for Exploit and Impact potential. This category represents the scenario where the security community members are telling us this is important, even though it’s not illustrated in the data at this time.

https://www.ncsc.gov.uk/section/advice-guidance/all-topics?allTopics=true&topics=critical%20national%20infrastructure%20(cni)&sort=date%2Bdesc

▲

Critical National Infrastructure (CNI)

National assets that are essential for the functioning of society, such as those associated with energy supply, water supply, transportation, health and telecommunications.

https://www.ncsc.gov.uk/section/advice-guidance/all-topics?allTopics=true&topics=artificial%20intelligence&sort=date%2Bdesc

▲

Artificial intelligence

Artificial intelligence (AI) describes computer systems which can perform tasks usually requiring human intelligence. This could include visual perception, speech recognition or translation between languages.

https://www.ncsc.gov.uk/section/advice-guidance/all-topics?allTopics=true&topics=social%20media&sort=date%2Bdesc

▲

Social media

Websites and apps, such as Facebook, X and Instragram, that allow people to share and respond to user-generated content (text posts, photos and video).

https://www.ncsc.gov.uk/section/advice-guidance/all-topics?allTopics=true&topics=cloud&sort=date%2Bdesc

▲

Cloud

An on-demand, massively scalable service, hosted on shared infrastructure, accessible via the internet. Typical services include providing data storage, data processing, and pre-built functionality, such as logging.

https://www.ncsc.gov.uk/section/advice-guidance/all-topics?allTopics=true&topics=cyber%20strategy&sort=date%2Bdesc

▲

Cyber strategy

A long-term plan of action with the aim of implementing cyber security.

https://www.ncsc.gov.uk/section/advice-guidance/all-topics?allTopics=true&topics=asset%20management&sort=date%2Bdesc

▲

Asset management

Identifying and recording of an organisation's physical assets, software, data, essential staff and utilities.

https://www.ncsc.gov.uk/section/advice-guidance/all-topics?allTopics=true&topics=configuration%20management&sort=date%2Bdesc

▲

Configuration management

Processes for defining and maintaining the consistency of configurations of software, hardware and other elements of an organisation to ensure reliable performance through its life.

https://www.ncsc.gov.uk/section/advice-guidance/all-topics?allTopics=true&topics=device&sort=date%2Bdesc

▲

Device

Computer-based hardware that physically exists, such as a desktop computer, smartphone or tablet.

Allmänt · ‽IT · ∴ · interrobangit · § · §IT

Dela · Kommentera

1 2 3 4 5 6 7 8 9 10

interrobangit

Gå till gästboken

Svenn Dybvik presentation ▼

Svenn Dybvik

Visa presentation

Svenn Dybvik

Lenkebenker

KONTAKT

reservoar residuum

2024
2023
- December (5)
- November (4)
- Oktober (5)
- September (4)
- Augusti (4)
- Juli (5)
- Juni (4)
- Maj (4)
- April (5)
- Mars (4)
- Februari (4)