[Owasp-leaders] Memory Protection Cheat Sheet

Jim Manico jim.manico at owasp.org
Sat Jan 25 22:46:54 UTC 2014


Ping! Recent credit card thefts make the proposed memory protection cheat
sheet all the more relevant and important.

Does anyone want to champion a memory protection cheat sheet?

Drop me a line if interested. Scratch notes on the topic below.

Aloha,
- Jim

-----Original Message-----
From: Jim Manico [mailto:jim.manico at owasp.org]
Sent: Monday, November 04, 2013 4:33 AM
To: owasp-leaders at lists.owasp.org
Subject: Memory Protection Cheat Sheet

Would anyone like to champion and complete a "Memory Protecting Cheat
Sheet" for us? Here are some scratch notes on the topic to help get you
started. Drop me a line if you are interested.


> PCIDSS 3 will be published in a couple of weeks time. It is likely
> there will be a new requirement regarding the insecure handling of PAN
> and SAD in
> memory:
>
> Considerations for cardholder data in memory
> http://www.bankinfosecurity.com/interviews/pci-30-draft-guidelines-rel
> eased-i-2034
>
> The latest Verizon report also mentioned a new type of malware is
> aiming at grabbing valuable data from memory in point-of-sale systems
"RAM scrapers".
> I think it would be good if there was a matching cheat sheet by then,
> perhaps called something like:
>
> "Memory Protection Cheat Sheet"
>
>
>    - What data might be relevant?
>       - Encryption keys
>       - Payment cardholder data - primary account number (PAN) and
>       sensitive authentication data (SAD)
>       - Government-issued identifiers
>       - Personal data (e.g. health, relating to children/minors)
>       - Financial data
>       - Intellectual property and trade secrets
>       - ???
>    - Attacks
>       - Memory scraping
>       - Theft of memory dumps
>       - ???
>    - Minimising amount of data brought into process memory (including
>    stacks)
>       - Avoid collecting data in the first place
>       - Avoid storing the data at all
>       - Delete data (from stores) as soon as it is not required, or
exceeds
>       the stated data retention period
>       - Never bring such data into memory unless absolutely required
>          - Prevent data access layer including such data fields by
default
>          - Prevent inclusion of these data fields in automated object
>          instantiation
>          - ???
>          - Only have tokenised or encrypted or hashed or truncated data
in
>       memory whenever possible
>       - ???
>    - Minimising the period data exposed in memory
>       - Encrypt or tokenise or hash or truncate immediately on receipt
>       - Overwrite/erase memory as soon as the data is not needed for
>       processing
>       - ???
>    - Minimising memory data written to other locations
>       - Disable use of caches such as swap files?
>       - Exclude from logs
>       - Manage garbage handling?
>       - Manage memory dumps?
>       - ???
>    - General development measures
>       - Eliminate vulnerabilities that can lead to the overwriting of
>       memory (e.g. buffer overflows, arbitrary memory write, alteration
of a
>       memory pointer)
>       - Do not use deprecated functions
>       - Develop/utilise a centralised/standard input data validation for
>       all untrusted data inputs
>       - Enable and use inbuilt operating system memory protection
measures
>          - ASLR
>          - DEP
>          - ???
>       - Enable and use inbuilt language/framework protection measures
(see
>       below)
>       - Use latest compilers
>       - Set complier options that enable memory protection options
>       - Implement application attack detection to defeat attackers
>       attempting to enumerate memory vulnerabilities
>       - ???
>    - General verification activities
>       - Perform code review around memory access, erasing and handling
of
>       these data
>       - Test the actual persistence of data in memory
>       - Test whether such data exists anywhere in the file system,
>       temporarily or otherwise
>       - ???
>    - Memory protection for .Net applications
>       - SecureString
>       - ???
>    - Memory protection for Java applications
>       - J2EE
>       - ???
>          - Spring
>          - ???
>          - Struts
>          - ???
>          - ???
>          - ???
>          - Memory protection for PHP applications
>          - ???
>          - Memory protection for Cobol applications?
>          - ???
>          - Memory protection for iOS applications
>          - ???
>          - Memory protection for Android applications
>          - ???
>          - Related infrastructure/server/device memory protection
measures
>       - Remove or disable system un-necessary components
>       - Apply security patches for all remaining system components
>       - Change all default credentials
>       - Limit inbound and outbound access from/to other systems to only
the
>       necessary ports, protocols, and services
>       - Replace weak software components with ones that support enhanced
>       memory protection (e.g. update DLLs)
>       - Limit physical and logical access to servers/devices where such
>       data is processed in memory
>       - Limit access to memory dumps, crash reports, etc
>       - Enable system and application event logging
>       - Monitor running processes
>       - Install and maintain anti-malware
>       - Install and maintain file integrity monitoring software
especially
>       operating system and temporary files/locations
>       - Monitor configuration changes such as the installation of new
>       services
>       - Use intrusion detection to defeat attempts to exploit memory
>       protection measures
>       - Monitor and investigate alerts from all above systems, and
ensure
>       their continued integrity


More information about the OWASP-Leaders mailing list