module: future of secure programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• fuzz testing...
TRANSCRIPT
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Module: Future of Secure Programming
Professor Trent JaegerPenn State University
1
1
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Programmer’s Problem
• Implement a program
‣ Without creating vulnerabilities
• What is a vulnerability?
2Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Little Survey
2
• What does “program for security” mean?
• Have you ever “programmed for security”?
• When do you start to consider security when you program?
• What do you try to do to make your code “secure”?
• When do you know you are done making your code “secure”?
• Should a programmer fix every flaw in their programs?
2
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Programmer’s Problem
• Implement a program
‣ Without creating vulnerabilities
• What is a vulnerability?
3
3
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Software Vulnerabilities• Vulnerability combines
‣ A flaw
‣ Accessible to an adversary
‣ Who can exploit that flaw
• Which would you focus on to prevent vulnerabilities?
4
4
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Buffer Overflow Detection• For C code where
‣ char dest[LEN]; int n;
‣ ...
‣ n = input();
‣ ...
‣ strncpy(dest, src, n);
• Can this code cause a buffer overflow?
5
5
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Runtime Analysis• One approach is to run the program to determine how it behaves
• Analysis Inputs
‣ Input Values - command line arguments
‣ Environment - state of file system, environment variables, etc.
• Question
‣ Can any input value in any environment cause a vulnerability (e.g., exploit a buffer overflow)?
• What are limitations of runtime analysis?
6
6
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Fuzz Testing• Dynamic software testing technique …
‣ Run the software
• Where invalid, unlikely, and/or random inputs are provided to the program …
‣ See what happens
• To detect crashes, exceptions, etc.
‣ Which may be indicate of flaws that can be exploited
‣ How would this detect a buffer overflow?
• Fuzz testing is “black-box testing” — do not need to examine the program code to run
• Research in grey/white-box testing, but industry uses fuzzing
7
7
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Runtime Analysis• One approach is to run the program to determine how it behaves
• Analysis Inputs
‣ Input Values - command line arguments
‣ Environment - state of file system, environment variables, etc.
• Question
‣ Can any input value in any environment cause a flaw (e.g., buffer overflow)?
• What are limitations of runtime analysis?
8Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Static Analysis • Explore all possible executions of a program!
‣ All possible inputs !
‣ All possible states!
8 8
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Runtime Analysis• One approach is to run the program to determine how it behaves
• Analysis Inputs
‣ Input Values - command line arguments
‣ Environment - state of file system, environment variables, etc.
• Question
‣ Can any input value in any environment cause a flaw (e.g., buffer overflow)?
• What are limitations of runtime analysis?
9Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Static Analysis • Provides an approximation of behavior!
• �Run in the aggregate�!
‣ Rather than executing on ordinary states!
‣ Finite-sized descriptors representing a collection of states!
• �Run in non-standard way�!
‣ Run in fragments!
‣ Stitch them together to cover all paths!
• Runtime testing is inherently incomplete, but static analysis can cover all paths!
10
9
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Runtime Analysis• One approach is to run the program to determine how it behaves
• Analysis Inputs
‣ Input Values - command line arguments
‣ Environment - state of file system, environment variables, etc.
• Question
‣ Can any input value in any environment cause a flaw (e.g., buffer overflow)?
• What are limitations of runtime analysis?
10Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Static Analysis Example • Descriptors represent the sign of a value!
‣ Positive, negative, zero, unknown!
• For an expression, c = a * b!
‣ If a has a descriptor pos!
‣ And b has a descriptor neg!
• What is the descriptor for c after that instruction?!
• How might this help?!
11 10
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Runtime Analysis• One approach is to run the program to determine how it behaves
• Analysis Inputs
‣ Input Values - command line arguments
‣ Environment - state of file system, environment variables, etc.
• Question
‣ Can any input value in any environment cause a flaw (e.g., buffer overflow)?
• What are limitations of runtime analysis?
11Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Descriptors • Choose a set of descriptors that !
‣ Abstracts away details to make analysis tractable!
‣ Preserves enough information that key properties hold!
• Can determine interesting results!
• Using sign as a descriptor!
‣ Abstracts away specific integer values (billions to four)!
‣ Guarantees when a*b = 0 it will be zero in all executions!
• Choosing descriptors is one key step in static analysis !
12
11
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Buffer Overflow Static Analysis• For C code where
‣ char dest[LEN]; int n;
‣ n = input();
‣ strncpy(dest, src, n);
• Static analysis will try all paths of the program that impact variable n and flow to strncpy
‣ May be complex in general because
• Paths: Exponential number of program paths
• Interprocedural: n may be assigned in another function
• Aliasing: n’s memory may be accessed from many places
• What descriptor values do you care about for n?
12
12
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Limitations of Static Analysis• Scalability
‣ Can be expensive to reason about all executions of complex programs
• False positives
‣ Overapproximation means that executions that are not really possible may be found
• Accuracy
‣ Alias analysis and other imprecision may lead to false negatives
‣ Sound methods (no false negatives) can exacerbate scalability and false positives problems
• Bottom line: Static analysis often must be directed
13
13
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Preventing Vulnerabilities • What can the programmer do to secure their program?
14
14
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
15Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Denning’s Lattice Model • Formalizes information flow models!
‣ FM = {N, P, SC, /, >}
• Shows that the information flow model instances form a lattice!
‣ N are objects, P are processes,!
‣ {SC, >} is a partial ordered set,!
‣ SC, the set of security classes is finite,!
‣ SC has a lower bound, !
‣ and / is a lub operator!
• Implicit and explicit information flows!
• Semantics for verifying that a configuration is secure!
• Static and dynamic binding considered!
• Biba and BLP are among the simplest models of this type
15-1
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
15
• What is it?
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Denning’s Lattice Model • Formalizes information flow models!
‣ FM = {N, P, SC, /, >}
• Shows that the information flow model instances form a lattice!
‣ N are objects, P are processes,!
‣ {SC, >} is a partial ordered set,!
‣ SC, the set of security classes is finite,!
‣ SC has a lower bound, !
‣ and / is a lub operator!
• Implicit and explicit information flows!
• Semantics for verifying that a configuration is secure!
• Static and dynamic binding considered!
• Biba and BLP are among the simplest models of this type
15-2
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
15
• What is it?
‣ Simple security & ★-property
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Denning’s Lattice Model • Formalizes information flow models!
‣ FM = {N, P, SC, /, >}
• Shows that the information flow model instances form a lattice!
‣ N are objects, P are processes,!
‣ {SC, >} is a partial ordered set,!
‣ SC, the set of security classes is finite,!
‣ SC has a lower bound, !
‣ and / is a lub operator!
• Implicit and explicit information flows!
• Semantics for verifying that a configuration is secure!
• Static and dynamic binding considered!
• Biba and BLP are among the simplest models of this type
15-3
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
15
• What is it?
‣ Simple security & ★-property
•
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Denning’s Lattice Model • Formalizes information flow models!
‣ FM = {N, P, SC, /, >}
• Shows that the information flow model instances form a lattice!
‣ N are objects, P are processes,!
‣ {SC, >} is a partial ordered set,!
‣ SC, the set of security classes is finite,!
‣ SC has a lower bound, !
‣ and / is a lub operator!
• Implicit and explicit information flows!
• Semantics for verifying that a configuration is secure!
• Static and dynamic binding considered!
• Biba and BLP are among the simplest models of this type
15-4
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
16Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Implicit and explicit flows • Explicit!
‣ Direct transfer to b from a (e.g., b = a)!
• Implicit!
‣ Where value of b may depend on value of a indirectly (e.g., if a = 0, then b = c)!
• Model covers all programs!
‣ Statement S!
‣ Sequence S1, S2!
‣ Conditional c: S1, …, Sm!
• Implicit flows only occur in conditionals!
16-1
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
16
• What is it?
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Implicit and explicit flows • Explicit!
‣ Direct transfer to b from a (e.g., b = a)!
• Implicit!
‣ Where value of b may depend on value of a indirectly (e.g., if a = 0, then b = c)!
• Model covers all programs!
‣ Statement S!
‣ Sequence S1, S2!
‣ Conditional c: S1, …, Sm!
• Implicit flows only occur in conditionals!
16-2
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
16
• What is it?
‣ Simple security & ★-property
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Implicit and explicit flows • Explicit!
‣ Direct transfer to b from a (e.g., b = a)!
• Implicit!
‣ Where value of b may depend on value of a indirectly (e.g., if a = 0, then b = c)!
• Model covers all programs!
‣ Statement S!
‣ Sequence S1, S2!
‣ Conditional c: S1, …, Sm!
• Implicit flows only occur in conditionals!
16-3
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
16
• What is it?
‣ Simple security & ★-property
•
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Implicit and explicit flows • Explicit!
‣ Direct transfer to b from a (e.g., b = a)!
• Implicit!
‣ Where value of b may depend on value of a indirectly (e.g., if a = 0, then b = c)!
• Model covers all programs!
‣ Statement S!
‣ Sequence S1, S2!
‣ Conditional c: S1, …, Sm!
• Implicit flows only occur in conditionals!
16-4
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
17Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Semantics
• Program is secure if:!
‣ Explicit flow from S is secure!
‣ Explicit flow of all statements in a sequence are secure (e.g., S1; S2)!
‣ Conditional c: S1, …, Sm is secure if:!
• The explicit flows of all statements S1, …, Sm are secure!
• The implicit flows between c and the objects in Si are secure!
17-1
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
17
• What is it?
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Semantics
• Program is secure if:!
‣ Explicit flow from S is secure!
‣ Explicit flow of all statements in a sequence are secure (e.g., S1; S2)!
‣ Conditional c: S1, …, Sm is secure if:!
• The explicit flows of all statements S1, …, Sm are secure!
• The implicit flows between c and the objects in Si are secure!
17-2
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
17
• What is it?
‣ Simple security & ★-property
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Semantics
• Program is secure if:!
‣ Explicit flow from S is secure!
‣ Explicit flow of all statements in a sequence are secure (e.g., S1; S2)!
‣ Conditional c: S1, …, Sm is secure if:!
• The explicit flows of all statements S1, …, Sm are secure!
• The implicit flows between c and the objects in Si are secure!
17-3
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
17
• What is it?
‣ Simple security & ★-property
•
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Semantics
• Program is secure if:!
‣ Explicit flow from S is secure!
‣ Explicit flow of all statements in a sequence are secure (e.g., S1; S2)!
‣ Conditional c: S1, …, Sm is secure if:!
• The explicit flows of all statements S1, …, Sm are secure!
• The implicit flows between c and the objects in Si are secure!
17-4
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Build on Type Safety
18
18-1
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Build on Type Safety
18
Example 1 Object obj;int i;obj = obj + i;
18-2
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Build on Type Safety
18
Example 1 Object obj;int i;obj = obj + i;X
18-3
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Build on Type Safety• A type-safe
language maintains the semantics of types. E.g., can’t add int’s to Object’s.
18
Example 1 Object obj;int i;obj = obj + i;X
18-4
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Build on Type Safety• A type-safe
language maintains the semantics of types. E.g., can’t add int’s to Object’s.
• Type-safety is compositional. A function promises to maintain type safety.
18
Example 1 Object obj;int i;obj = obj + i;X
18-5
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Build on Type Safety• A type-safe
language maintains the semantics of types. E.g., can’t add int’s to Object’s.
• Type-safety is compositional. A function promises to maintain type safety.
18
Example 1 Object obj;int i;obj = obj + i;
Example 2 String proc_obj(Object o);...main(){ Object obj; String s = proc_obj(obj);
...}
X
18-6
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Labeling Types
19
19-1
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Labeling Types
19
Example 1 int{high} h1,h2;int{low} l;l = 5;h2 = l;h1 = h2 + 10;l = h2 + l;
19-2
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Labeling Types
19
Example 1 int{high} h1,h2;int{low} l;l = 5;h2 = l;h1 = h2 + 10;l = h2 + l;X
19-3
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Labeling Types
• Key insight: label types with security levels
19
Example 1 int{high} h1,h2;int{low} l;l = 5;h2 = l;h1 = h2 + 10;l = h2 + l;X
19-4
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Labeling Types
• Key insight: label types with security levels
• Security-typing is compositional
19
Example 1 int{high} h1,h2;int{low} l;l = 5;h2 = l;h1 = h2 + 10;l = h2 + l;X
19-5
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Labeling Types
• Key insight: label types with security levels
• Security-typing is compositional
19
Example 1 int{high} h1,h2;int{low} l;l = 5;h2 = l;h1 = h2 + 10;l = h2 + l;
Example 2 String{low} proc_obj(Object{high} o);...main(){ Object{high} obj; String{low} s; s = proc_obj(obj); ...}
X
19-6
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Implicit Flows
20
intLow mydata = 0;
intLow mydata2 = 0;
if (testHigh)
mydata = 1;
else
mydata = 2;
mydata2 = 0;
printLow(mydata2);
printLow(mydata);
…
Static (virtual) tagging
Causes type error at compile-time
mydata contains information about test so it can no longer be Low,but mydata2 is outside the
conditional, so it is untainted by test
20-1
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Implicit Flows
20
intLow mydata = 0;
intLow mydata2 = 0;
if (testHigh)
mydata = 1;
else
mydata = 2;
mydata2 = 0;
printLow(mydata2);
printLow(mydata);
…
Static (virtual) tagging
Causes type error at compile-time
mydata contains information about test so it can no longer be Low,but mydata2 is outside the
conditional, so it is untainted by test
20-2
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Retrofitting for Security• Take the code written in a language of the programmers’ choice (for
functionality) and retrofit with security code (mostly-automated)
• Consider authorization bypass vulnerabilities
‣ In these vulnerabilities, programmers forget to add code to control access to program resources
21
Resource manager!
!!
Resource user!
Operation request! Response!
Authorization policy!
Reference monitor!
Allowed?! YES/NO!
Authorization Hooks!
‹Alice, /etc/passwd, File_Read›!
What!is!authoriza,on?!!
21
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Retrofitting for Security• Take the code written in a language of the programmers’ choice (for
functionality) and retrofit with security code (mostly-automated)
• Consider authorization bypass vulnerabilities
‣ In these vulnerabilities, programmers forget to add code to control access to program resources
22Systems and Internet Infrastructure Security (SIIS) Laboratory Page
X Server & Many X Clients
REMOTE
LOCAL
22
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Retrofitting for Security• Take the code written in a language of the programmers’ choice (for
functionality) and retrofit with security code (mostly-automated)
• Consider authorization bypass vulnerabilities
‣ In these vulnerabilities, programmers forget to add code to control access to program resources
23Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Malicious Remote X Client
REMOTE
LOCAL
23
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Retrofitting for Security• Take the code written in a language of the programmers’ choice (for
functionality) and retrofit with security code (mostly-automated)
• Consider authorization bypass vulnerabilities
‣ In these vulnerabilities, programmers forget to add code to control access to program resources
24Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Illegal Information Flow
REMOTE
LOCAL
24
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Retrofitting for Security• Take the code written in a language of the programmers’ choice (for
functionality) and retrofit with security code (mostly-automated)
• Consider authorization bypass vulnerabilities
‣ In these vulnerabilities, programmers forget to add code to control access to program resources
25Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Desirable Information Flow
LOCAL
REMOTE
25
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to all security-sensitive
window objects in the X Server are authorized?
26
26
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
27Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Program Challenges
A. Identify security-sensitive resources
• Programs manipulate many variables• 7800 in X Server• Of over 400 structures • Many, many structure-
member accesses
Program Challenges
Inferring Sensitive Operations
BRequest Interface
i
C
User A
User B
D
A
FI
JH
K
L
E
Program
o1
o2
o3
o4
on
.
.
.
27
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
28Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Solution
• In servers, client-request determines choices that client
subjects can make in the program
• “Choice”:
‣ Resources: Determine which elements are chosen from
containers.
‣ Operations: Determine which program path
is selected for execution.
Requests make choices
28
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
29Systems and Internet Infrastructure Security (SIIS) Laboratory Page
o1
o2
o3
o4
BRequest Interface
i
Cv = Lookup(O,i)
User A
User B
D
A
FI
JH
K
L
E
Program
Container O
Idea: Request ChoicesLookup Function using tainted variable
29
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
30Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Idea: Request Choices
o1
o2
o3
o4
BRequest Interface
i
Cv = Lookup(O,i)
User A
User B
D
A
FI
JH
K
L
E
Program
Container O
Op 1.0
30
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
31Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Idea: Request Choices
write v
o1
o2
o3
o4
BRequest Interface
i
Cv = Lookup(O,i)
User A
User B
D
A
FI
JH
read v
K
L
E
Program
Container O
Op 1.0
Control Statement Predicated on atainted variable
31
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
32Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Idea: Request Choices
write v
o1
o2
o3
o4
BRequest Interface
i
Cv = Lookup(O,i)
User A
User B
D
A
FI
JH
read v
K
L
E
Program
Container O
Op 1.0
Op1.3Op1.2Op1.1
Choice of operations
32
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
33Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Idea: Request Choices
write v
o1
o2
o3
o4
BRequest Interface
i
Cv = Lookup(O,i)
User A
User B
D
A
FI
JH
read v
K
L
E
Program
Container O
Op 1.0
Op1.3Op1.2Op1.1
Security sensitiveoperation
33
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Mediate SSOs• Where should we place authorization hooks?
• Mediate all security-sensitive operations found
‣ Good: Enforce least privilege flexibly
‣ Bad: Maximal number of hooks means…
• Ensure at least one hook per security-sensitive operation
‣ Good: Minimal number of hooks
‣ Bad: Must ensure that all authorized subjects pass…
• Idea: Determine if you have blocked enough
‣ Suppose OP-1 dominates OP-2, then if policy for OP-1 blocks all the unauthorized subjects for OP-2…
34
34
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Future of Secure Programming• Write your program with functionality in mind
• Determine security policies to be enforced on the program
‣ Semi-automated - e.g., use program analysis to find SSOs
• Use security policies to guide retrofitting of program with security code automatically
• Can it be done?
‣ Caveat: Some security knowledge is application-specific
‣ Caveat: Cannot retrofit for security from program code alone
35
35
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Take Away• Programming for security is difficult
‣ Programmers create “flaws” that are often accessible and exploitable by adversaries (vulnerabilities)
• Program analysis can find some flaws
‣ Static and dynamic, but limitations for each
• May need to fix program - security types and “choice”
• The future of secure programming may look very different
‣ Now: use favorite language for achieving function and try to add security code without creating flaws
‣ Future: use favorite language for achieving function and retrofit based on a “security program”
36
36