Saturday, November 13, 2021

International research and new Privacy laws

A lot of research subscribes the following format: find an answer first and then worry about the consequences later. There are books, papers, and movies dealing with this. In fact, this is a perennial Science Fiction topic. Henry K. Beecher once said that "the problem was not that researchers were malicious or evil; rather the problem was they manifested thoughtlessness or carelessness."

The way research has been performed changed throught the years. Depending on the chosen topic, American scientists have to comply -- grungly at times because some think it hampers their style -- policies set forth by their institutions and funding agencies such as (small sample otherwise we will be here all day) Health Insurance Portability and Accountability Act (HIPAA), the Family Educational Rights and Privacy Act (FERPA), the Gramm-Leach-Bliley Act (GBLA), the Federal Information Security Modernization Act (FISMA), and the NIST sp 800-171. Doing research with international partners makes life even more interesting: now we need to know which rules these partners have to play under. That goes doubly so when dealing not only with security but specially privacy ones, which cover the test subjects and their data and the researchers themselves. Of these, the most famous is the European General Data Protection Regulation (GDPR), but it is not the only one. In a NFS-funded international experimental testbed project I worked on, I had to deal with GDPR, the Brazilian General Personal Data Protection Law (LGPD), and the Japanese Act on the Protection of Personal Information (APPI).

One of the most important points in these laws is the scope: they are applicable if you are intentionally trying to provide a business or a service to someone residing (not necessarily a citizen) in Brazil, the European Union, or Japan. In our case, we were attracting researchers -- from principal investigators to grad students -- in those countries; therefore, we checked that box.

Here are the most interesting differences between the 3; in blue are where one regulation is more restrictive than other. The idea here is that if you need to deal with all of them, plan to satisfy all the blues.

Shameless plugin

In October 18–21 I had the opportunity to participate in the NSF 2021 Cybersecurty Summit, which is run by TrustedCI, both as a presenter and as a workshop co-chair (fancy term for catherder). The talk I gave was called "GDPR, APPI, and LGPD: don’t go sciencing internationally in your experimental testbed without knowing them," which covers some of the topics raised in this article. But, don't take my word for it! They made the videos available in Nov 2, so you too can enjoy seeing me realizing the 1h talk I prepared needs to be presented in less than 30 minutes.

I know you can't see it, but I am sporting an ioactive t-shirt; no, it was not because it was laundry day.

References

Security and Privacy Certifications and CPEs

This may not sound like a security/privacy-related topic, but there is more to these professions than wearing hoodies with 'l337 H4ck3rz' written on its back.

Early this year I earned the ISACA Certified Data Privacy Solutions Engineer (CDPSE). They do issue pretty badges to put in your website to impress your friends and be the life of the party:

The thing is, if you want to keep your hard earned (and usually not cheap) professional credentials, you need to do some professional development, which is measured using Continuing Professional Education (CPE) credits. Before you put your surprised face on, understand this is not specific to IT and InfoSec industry. The first time I learned about that was in the medical industry: over there it is called Continuing Medical Education (CME), but the principle is the same.

ISACA is not the only place requiring CPEs; if you have a (ISC)2 (I am looking at you, CISSP holders) or CompTIA certification, chances are you too need some CPEs. Given the cost of the CISSP, the last thing you want to do is lose it because you did not spend the time to get the required amount of CPEs. For the sake of this discussion I will focus on how ISACA handles CPEs. According to this certification requirements, I need

  • 20 CPEs annually
  • 120 CPEs every 3 years

Two things I would like to point out:

  1. The 3 year cycle you need to earn the 120 CPEs start in the year after you are certified. So, for me that would be 2022 to 2024.
  2. You need to earn the CPEs for a given year X in the year X - 1. In my case, I was certified in 2021, so I need to earn and submit my CPEs in 2021 for the year 2022.
  3. The math is a bit scary: you need a total of 120 CPEs in a 3 year interval; that means an average of 40 CPEs/year. If you have done the bare minimum -- 20 CPEs -- each year for years 1 and 2, in the last year you will need to come up with 80 CPEs. At the time I wrote this, my CPE count looks like this:
    I covered the bare minimum for 2022 but it would be better if I come up with another 9 CPEs.

So, how do we earn some nice free-range CPEs? ISACA does publish a doc on how to earn them. Some you can earn by doing things associated with them, like going to their conferences or taking their training classes. But you can also eanr them through other activities such as

  • Teaching / Lecturing / Presenting: This is how I got most of my CPEs this year, thanks to the talks and the workshops I gave. You can earn a lot of them.
  • Publication of Articles, Monographs and Books: Last article I wrote that was published happened last year, so it does not count. But, maybe you did something, as it earns you a lot of CPEs.
  • Self-study Courses: I took a class -- Certified Cyber Security Architect -- in March of this year, so I could add some CPEs. I am also taking another class right now; I will contact the instructor to see if I can get CPEs trough it too.
  • Non-ISACA Professional Education Activities and Meetings: In other words, attending monthly meetings, say the ISSA one, count as a way to earn a few more CPEs. Not much (I think one per meeting) but every little bit counts.
  • Passing Related Professional Examinations: I did not realize I could also earn them this way, so I have a few more to add. Two CPEs per examination add up.
  • Vendor Sales/Marketing Presentations: Suck it up and watch that infomercial webinar!
There are more events but these are the ones I have used.

Bottom Line

There is no excuse for you to lose a certification due to lack of CPEs! If I can do it, so can you!

Tuesday, November 2, 2021

No Bsides Zurich this year

This post is a bit of a vent. On Sept 30th (the deadline; talk about waiting for the last moment!) I submitted a talk to the Bsides Zurich this year. Yesterday I received an email saying, well, they were cancelling it. It seems they were planning on, instead of having a virtual or live event, publishing a book. But, since they did not have enough articles they chose to can it. It seems that I misunderstood their CFP. Bummer

My gripe: I understand they would not want to have a live event because of COVID, but why not have a virtual one in addition to the book? On well. Better luck next year.

Sunday, August 8, 2021

Is your phone plotting against you?

There is say that states when cats nap, they dream of plots to kill their "owners."

What about phones?

Ok, maybe phones are not planning on killing you, and should have grown out of their arsonistic phase, but that does not stop them from being up to no good. You see, they are always sending information about your location, what you are saying (Alexa and Siri, I am looking at both of you), what you have searched for or bought, and even pictures and videos (think taking a protored exam at home, but creepier). Bottom line is smart phones are little snitches: they compromise your privacy by design.

There are things that can be done to minimize the impact of this intentional data exfiltration both in a behavioral and technological level; that was the topic of the workshop "Practically Protecting Phone Privacy" we presented earlier today at the DEFCON 29's Crypto and Privacy village. I was going to write about it after we were finished, but after 4h of almost nonstop -- we just took 10min breaks every hour -- I was braindead. Understand I was up since 5pm checking and rechecking the slidedeck, the timing, and the demo. The latter did not happen because of network connectivity issues (we were doing this remote). Good thing we planned for that and had a set of screen captures -- phone, Android tools, etc -- to show the different steps. That does not make me happy since I bought 2 phones specifically for that part of the workshop, but, as one of the slides in our presentation says, we need to get out of our comfort zone.

We created a github repo to put the docs and links associated with this talk. It started as instructions to set phones up before the workshop but we plan on adding more stuff. As a result, it is a work in progress (the nicer term is living document).

Right now I still feel braindead (as my typos demonstrate) so it will take a while until I add something clever to this thread. Still, at least I would like to thank the folks at Crypto and Privacy village for having us and putting up with our troubles and shenanigans.

Saturday, August 1, 2020

Article Published at ISSA!

Our article "Converging Data Privacy and Security" was accepted for publication in the August issue of the ISSA Journal! The physical issue has not showed up in my mailbox yet, but I found it is availble (as a PDF) to members right now. This is a great wat to start the day; publishing something in a printed magazine has a different feel than giving a talk or workshop.

Fun fact: We submitted it before the June 8 deadline to be in the July issue, called Security vs Privacy Tug of War but there were too many reviews to be made and it did not make it in time. We will do better next time; like most things, there is a learning curve. Still, the deed is done and that is all that matters!

Per ISSA policy, "all articles become the property of the ISSA Journal for a period of 12 months, after which copyright reverts to the author." Until then, we cannot post it. If you are an ISSA member, you know how to get a copy.

I know this will sound cheesy but I do appreciate the patience the editor, Thom Barrie, had with us. Let's just say we were at times rather annoying.

Thursday, August 29, 2019

FIDO Alliance, StongKey, and OWASP

I need to catch some Zs, so I will try to update this article tomorrow.

Earlier today Arshad Noor gave a talk at our local OWASP chapter. He represents StrongKey (they have the octopus whose face seems to imply he knows what Tux did to have that look on his face) at the FIDO Alliance, and talked about the need and evolution of multifactor authentications systems. The part I was interested is separating the authentication from having physical access to the system you want to connect to; the former would be something like Yubikey. Application here is those servers we all need to remote access. The only part I do not like is that we are still stuck to using an app in a smartphone for that.

Monday, October 15, 2018

Creating a .E01 forensics file from command line in Linux

If you have dealt with forensics, chances are you might have bumped with a .E01 file or two. That filetype is known as Expert Witness Compression Format (EWF), which is a proprietary image file format created by Guidance Software for their Windows-based forensic software family known as EnCase (used to be called Expert Witness). The idea (the following may sound like an infomercial) is that when you need to preserve a copy of the drive of a computer for forensics (duh!) analysis (and digital evidence), then run the program to create a snapshot of the disk, hidden and unallocated areas included. The file also keeps track of case info, including when investigators accessed it, while allowing to see the contents without changing them or their file stamps. This way, the chain of custody as defined by ASTM E1459-13, is preserved.

The Tools

I have used this program and it does its job well. But, I use Linux most of the time; can I replicate what it does just enough so I can create a proper .E01 file? Enter Joachim Metz. Hey may not be Bruce Lee but he did kick some ass by creating Libewf, a Linux/OSX open source tool to create and handle not only the .E01 file format but also .Ex01 and .Lx01. Source code can be found on github, but I will be lazy and get it as a package.

Steps

  1. Get the software. It is available on debian/ubuntu as ewf-tools:

    ewf-tools - collection of tools for reading and writing EWF files

    I did not check on CentOS or Arch, but I expect both to have it too. In any case, install the package any way you feel like.

  2. Get the drive we want to investigate. Usually we would boot the compromised system using a carefulyl crafted live USB disk, or mount the drive we cant to copy into our forensics computer. In this case we will be lazy because we just want to go through the motions: we will use the disk image foretest.iso created for an article in my other blog earlier this year.
    -rw-rw-r-- 1 raub raub 1073741824 Dec 13  2018 ./dev/hack/foretest.iso

    This image will play the part of a suspicious drive we want to do some forensics on. Just a FYI, I made a copy of foretest.iso and am working from that. I know that does not replicate real life, but I like to follow

    Rule #1: Always work from a copy.

    So,

    raub@desktop:~$ cp dev/hack/foretest{,_test}.iso
    raub@desktop:~$ ls -l dev/hack/foretest*
    -rw-rw-r-- 1 raub raub 1073741824 Oct 02 17:29 dev/hack/foretest.iso
    -rw-rw-r-- 1 raub raub 1073741824 Oct 13 13:37 dev/hack/foretest_test.iso
    raub@desktop:~$ sha256sum dev/hack/foretest*.iso
    49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  dev/hack/foretest.iso
    49bc20df15e412a64472421e13fe86ff1c5165e18b2afccf160d4dc19fe68a14  dev/hack/foretest_test.iso
    raub@desktop:~$
  3. Create the .E01 file. We should not try to mount the drive because that can change its contents somehow. Instead we are passing it as an argument; if it was a physical drive we could pass it as, say ,tt>/dev/sdd. During the startup, it asks a few questions to create the forensics case; remember chain of command!
    raub@desktop:~$ ewfacquire -t dev/hack/forensics/001_2018_Suspicious dev/hack/fo
    retest_test.iso
    ewfacquire 20140807                                                             
    
    Storage media information:                                                      
    Type:                                   RAW image
    Media size:                             1.0 GB (1073741824 bytes)
    Bytes per sector:                       512
                                                                                    
    Acquiry parameters required, please provide the necessary input                 
    Case number: 001
    Description: Strange growth I found under my armpit on a summerday morning
    Evidence number: 001
    Examiner name: Clueless Bob                                                     
    Notes: File is not in the right shade of fuscia                                 
    Media type (fixed, removable, optical, memory) [fixed]: 
    Media characteristics (logical, physical) [physical]: 
    Use EWF file format (ewf, smart, ftk, encase1, encase2, encase3, encase4, encase
    5, encase6, linen5, linen6, ewfx) [encase6]: ewf                             
    Compression method (deflate) [deflate]:                                         
    Compression level (none, empty-block, fast, best) [none]: 
    Start to acquire at offset (0 <= value <= 1073741824) [0]: 
    The number of bytes to acquire (0 <= value <= 1073741824) [1073741824]: 
    Evidence segment file size in bytes (1.0 MiB <= value <= 1.9 GiB) [1.4 GiB]: 
    The number of bytes per sector (1 <= value <= 4294967295) [512]: 
    The number of sectors to read at once (16, 32, 64, 128, 256, 512, 1024, 2048, 40
    96, 8192, 16384, 32768) [64]: 
    The number of sectors to be used as error granularity (1 <= value <= 64) [64]: 
    The number of retries when a read error occurs (0 <= value <= 255) [2]: 
    Wipe sectors on read error (mimic EnCase like behavior) (yes, no) [no]: 
    
    The following acquiry parameters were provided:
    Image path and filename:                dev/hack/forensics/001_2018_Suspicious.e
    01
    Case number:                            001
    Description:                            Strange growth I found under my armpit o
    n a summerday morning
    Evidence number:                        001
    Examiner name:                          Clueless Bob
    Notes:                                  File is not in the right shade of fuscia
    Media type:                             fixed disk
    Is physical:                            yes                                     
    EWF file format:                        original EWF (.e01)
    Compression method:                     deflate                                
    Compression level:                      none                                    
    Acquiry start offset:                   0
    Number of bytes to acquire:             1.0 GiB (1073741824 bytes)              
    Evidence segment file size:             1.4 GiB (1572864000 bytes)
    Bytes per sector:                       512                                    
    Block size:                             64 sectors                              
    Error granularity:                      64 sectors
    Retries on read error:                  2                                       
    Zero sectors on read error:             no                                                                                                                      
    Continue acquiry with these values (yes, no) [yes]:                             
                        
    Acquiry started at: Oct 13, 2018 14:22:45                                       
    This could take a while.                                                                                                                                        
    Status: at 2%.                                                                  
            acquired 24 MiB (25919488 bytes) of total 1.0 GiB (1073741824 bytes).
            completion in 3 minute(s) and 16 second(s) with 5.1 MiB/s (5368709 bytes
    /second).                                                                                                                                                       
    Status: at 2%.                                                                  
            acquired 25 MiB (26705920 bytes) of total 1.0 GiB (1073741824 bytes).
            completion in 13 minute(s) and 53 second(s) with 1.2 MiB/s (1263225 byte
    s/second).
    [...]
    Status: at 97%.
            acquired 995 MiB (1044348928 bytes) of total 1.0 GiB (1073741824 bytes).
            completion in 15 second(s) with 2.0 MiB/s (2126221 bytes/second).
    
    Acquiry completed at: Oct 13, 2018 14:31:08
    
    Written: 1.0 GiB (1073742012 bytes) in 8 minute(s) and 23 second(s) with 2.0 MiB/s (2134675 bytes/second).
    MD5 hash calculated over data:          cd573cfaace07e7949bc0c46028904ff
    ewfacquire: SUCCESS
    raub@desktop:~$ 
    
    

    This was rather fast because the drive was just 1GB. In a real case it would have taken hours. Note it did not ask to encrypt 001_2018_Suspicious.e01; I do not know if that is a limitation of the code or just me who should have read the docs before writing this up. And, I can't keep a straight face about the MD5 sum. The resulting file looks like this

    raub@desktop:~$ ls -lh dev/hack/forensics/
    total 1.1G
    -rw-r--r-- 1 raub raub 1.1G Oct 13 14:31 001_2018_Suspicious.e01
    raub@desktop:~$ 

    Note it is bigger than the original file as it adds all the information we mentioned. Let's see what it knows about the file

    raub@desktop:~$ ewfinfo  dev/hack/forensics/001_2018_Suspicious.e01             
    ewfinfo 20140807
                        
    Acquiry information                                                             
            Case number:            001                                             
            Description:            Strange growth I found under my armpit on a summ
    erday morning  
            Examiner name:          Clueless Bob                                   
            Evidence number:        001                                             
            Notes:                  File is not in the right shade of fuscia
            Acquisition date:       Sat Oct 13 14:22:45 2018
            System date:            Sat Oct 13 14:22:45 2018                       
            Password:               N/A                                             
    
    EWF information
            File format:            EnCase 1                                        
            Sectors per chunk:      64                                              
            Compression method:     deflate
            Compression level:      no compression
                                                                                    
    Media information                                                               
            Media type:             removable disk
            Is physical:            no                                              
            Bytes per sector:       512                                             
            Number of sectors:      2097152                                                 
            Media size:             1.0 GiB (1073741824 bytes)
                        
    Digest hash information                                                         
            MD5:                    cd573cfaace07e7949bc0c46028904ff         
    
    raub@desktop:~$ 

    and verify its integrity.

    raub@desktop:~$ ewfverify  dev/hack/forensics/001_2018_Suspicious.e01 
    ewfverify 20140807
    
    Verify started at: Oct 13, 2018 14:46:17 
    This could take a while.
    
    Status: at 4%.
            verified 44 MiB (46891008 bytes) of total 1.0 GiB (1073741824 bytes).
            completion in 1 minute(s) and 36 second(s) with 10 MiB/s (10737418 bytes
    /second).
    
    [...]
    Status: at 94%.
            verified 972 MiB (1019871232 bytes) of total 1.0 GiB (1073741824 bytes).
            completion in 5 second(s) with 11 MiB/s (12064514 bytes/second).
    
    Verify completed at: Oct 13, 2018 14:47:43
    
    Read: 1.0 GiB (1073741824 bytes) in 1 minute(s) and 26 second(s) with 11 MiB/s (12485370 bytes/second).
    
    MD5 hash stored in file:                cd573cfaace07e7949bc0c46028904ff
    MD5 hash calculated over data:          cd573cfaace07e7949bc0c46028904ff
    
    ewfverify: SUCCESS
    raub@desktop:~$ 

    Yes, more MD5-ness for your amusement. I was going to go over mounting/accessing 001_2018_Suspicious.e01 but just realized this article has become rather long. I will go over that part in a future article.

References