平成30/ 2018-10-23 21:59
iOS/Security Overview

>> About Software Security

In the cloud-enabled, highly networked world of modern computing, security is one of the most important facets of proper software engineering.

The most important thing to understand about security is that it is not a bullet point item. You cannot bolt it
on at the end of the development process. You must consciously design security into your app or service from
the very beginning, and make it a conscious part of the entire process from design through implementation,
testing, and release.


>> At a Glance

At the application layer, security means being aware of how your code uses information and ensuring that it
does so safely and responsibly. For example, it is your responsibility to:


● Keep users’ personal data safe from prying eyes. Store the data in a secure way, and ensure that your
software collects only the information that it requires.
● Treat untrusted files and data with care. If your software accesses the Internet or reads files that might
have previously been sent to someone over the Internet, your software must properly validate the data.
If it does not, it might inadvertently provide a vector for attackers to access other personal data that may
be stored on the user’s computer or other mobile device.
● Protect data in transit. If your software transmits personal information over the Internet, you must do so
in a safe and secure fashion to prevent unauthorized access to or modification of the data while in transit.
● Verify the authenticity of data where possible. If your software provides access to or works with signed
data, it should verify those signatures to ensure that the data has not been tampered with.


>> Threat Models Help You Identify Areas of Risk

In the planning phase, you must determine the nature of the threats to your software and architect your code in such a way that maximizes security. To do this, you should build up a threat model that shows ways in which your software might be attacked.
RelevantChapter: “RiskAssessmentandThreatModeling”(page8)


>> Secure Coding Techniques and OS Security Features Help You Mitigate Those Risks

At each phase of the development process, you must take steps to mitigate risks:
Avoid exploitable coding flaws. During the implementation phase, you must avoid using insecure coding techniques that can lead to arbitrary code injection, denial of service, or other incorrect behavior.
Update your risk model continuously. Throughout the development process, you should continue to perform regular risk assessments and update your threat model as the software evolves so that it accurately reflects your risk.
Don’t reinvent the wheel. When securing your software and its data, you should always take advantage of built-in security features rather than writing your own if at all possible. In particular, you may need to determine whether a user is legitimate or not, send messages to servers securely to protect the integrity and secrecy of data in transit, or store data securely on local disks to protect data at rest.
RelevantChapters: “CodeSecurity”(page15),“RiskAssessmentandThreatModeling”(page8), “Authentication and Authorization” (page 20), “Cryptographic Services” (page 23)


>> Tools Can Help You Catch Coding Errors

In the testing phase, you should take advantage of static analyzers and other tools designed to help you find security vulnerabilities.

Relevant Chapters: “Other Security Resources” (page 38)

>> Prerequisites

This document assumes that you have already read Mac Technology Overview , iOS Technology Overview , or both.

>> Risk Assessment and Threat Modeling

Before you write a single line of code, take the time to design your software with security in mind.

Doing this correctly is genuinely hard; if your security analysis process seems easy, you’re probably missing something fairly fundamental and losing most of the benefits of proper secure code design.

Risk assessment and threat modeling happens in three steps:

1. Assess risk. Determine how much you have to lose.

2. Determine potential threats. Figure out the various things your code does that could be attacked (including things that frameworks and libraries do on your behalf ).
2。潜在的な脅威を特定します。 (フレームワークやライブラリは、あなたに代わって行っていることを含む)を攻撃対象となるコードがない様々なことを把握。

3. Mitigate threats. Ensure that the parts of your code that could be attacked are well protected.

>> Assessing Risk

To assess the risk that your code would pose if compromised, you should first assume that your program will be attacked.

>> Assume Your Software Will Be Attacked

The amount of time and effort that an attacker will spend attacking your program depends on several factors, including:

● The value of the data your program handles. Does it store thousands of credit card numbers or a user’s recipe collection?

● The trustworthiness and security of companies who provide services that your code depends on.

● The specific clients who purchased your program. Is your word processing app being used by Joe’s Auto Repair or by Big Megacorp, Inc.?

● How widely your program will be distributed. Is it an app that is used by a single, small workgroup, or is it built into an operating system that is about to be released worldwide?

Based on those same factors, you need to decide what level of risk is acceptable.

A loss of data that will cost your company $1000 to rectify doesn't justify a $10,000 development effort to close all potential security bugs.

On the other hand, damage to your company's reputation might be worth far more in the long run than it would cost to design and develop secure code.

>> Evaluate the Risk

Here are some factors to consider when evaluating risk:

● What is the worst thing that can happen if your software is successfully attacked?

Will it allow theft of a user’s identity, allow an attacker to gain control of a user’s computer, or just enable a hacker to get an unusually high score in pinball?

● How hard is it to mount a successful attack?

If exploiting a vulnerability would require installing a Trojan horse on the user's computer that can take advantage of a race condition that occurs only once in 50 times the program starts up, you might decide the level of risk is acceptable.

If the exploit can be put into a script and used by script kiddies (attackers who run prewritten attack scripts) or be automated to spread by botnets (networks of compromised computers), the level of risk is much higher.

● How big a target is it?
Did you sell a hundred copies of your app, or is it installed by default on hundreds of thousands of
Is it vulnerable by default, or only after a user chooses an unusual set of options?
● How many users would be affected?
An attack on an end user’s machine usually affects one or two people, but a denial of service attack on a
server might affect thousands of users if even one server is attacked. Similarly, a worm spread by a common
email program might infect thousands of computers.
● How accessible is the target?
Does running the program require local access, or does the program accept requests across a network?
Is authentication required in order to establish a connection, or can anyone send requests to the program?

>> Thanks.
Security Overview