Gen Con 2015 Preview – Hacking in Media: The Good, The Bad, and The Ugly (2015 Edition)

It’s almost that time again! Johnny Xmas, Beltface, and myself will be returning next week to Gen Con 2015 in Indianapolis (under the Circle City Con flag) to begin the yearly rotation of our panel on the state of hacking in fiction.

Something I hear repeatedly mourned by infosec professionals is that there’s not enough outreach outside our relatively small community. We tend to speak at security conferences to people who mostly understand the issues at hand. Our group of speakers has been countering this by traveling to non-infosec geekdom cons to speak on basic hacking concepts. We educate by showing fictional movie, TV, book, and game segments from the past year that include hacking, and then discuss what worked and didn’t work (and why). We’ve had good luck with this – reaching students and hobbyists who aren’t familiar with the community, as well as writers and game designers who were slightly off track technically.

Hacking is a hot subject in fiction, but unfortunately, a lot of it is portrayed in absurd ways with some common fallacies repeated constantly. We usually break these misconceptions up into:

  • Magical Malware – It has no limits! It’s untraceable and unstoppable!
  • The ‘Many Windows Hack’ – Black and green windows everywhere, still.
  • Misappropriation of Terms – Using legit technical terms, totally wrong.
  • Logical vs. Physical Distance – The bad/good guys just have to be at THE server.
  • Magical Forensics – Done in seconds! With many blue lights!
  • Terrible Illustrations – Those horrible renderings of ‘cyberspace’ (these are getting less common)

We then demonstrate how those fallacies are seen in clips, rating their plausibility and technical accuracy from good, to bad, to ugly. I don’t want to spoil our talk for this year for those attending, but some examples at the top of our ‘good’ list for 2014-2015 are Mr. Robot, Halt and Catch Fire, and the game Hacknet. At the bottom of our ‘ugly’ list are shows like Scorpion and Arrow.

We’re looking for more non-infosec cons to give this talk at! Travel is a consideration, but please let us know if you know of a good venue. Also, if you work in infosec and would like to participate in one of our future panels, please contact me!

The Gamemaster’s Guide to Incident Response

I had the honor and pleasure of being asked to teach a four hour incident response class at last month’s Circle City Con in Indianapolis, IN (you can watch a recording, here). The subject was preestablished based on attendee interest: building an incident response program in small, medium, and large enterprises. Granted, most of the talks I give aren’t on spaceships or robots or other such entertaining stuff, but this in particular presented a conundrum – developing a program and team can be a spectacularly dry subject.

I approached the class with a few goals in mind:

1) I wanted to ensure I kept audience interest for the full four hours, (and maintained my ability to speak!)

2) I wanted to ensure every critical topic about building a team I presented was reinforced in an entertaining way.

and finally,

3) Maintaining audience involvement so that they would be offered auditory, visual, and hands on learning simultaneously, giving them the best chance of success possible.

The answer became obvious – I firmly believe that incident response is made of endless, great stories. Therefore, I would gamify building an incident response team, turning it into a story-based role playing game. I’d already had positive exposure to gamification in and out of infosec education – I regularly speak at gaming conventions about hacking. Now it was apparent that I was going to have to bring gaming to the hacking convention.

Gamification has been a key component of education for a long time, but it in the past it’s been pretty kid-specific. However, as gaming itself becomes more mainstream, teens and adults are becoming more and more comfortable in thinking of their lives in terms of games – accumulating achievements, reaching rewards through set goals, and learning through creative, fun activities. This has been reflected as the new, hot thing in everything from fitness apps to HR training – educators have discovered that people can often learn better and be more interested in fun, creative, and achievement-oriented environments.

The tremendous value gamification (and role playing in specific) brings to education is the creativity and emotional involvement it inspires. If I simply presented a case and explained my response, there’d be no emotional weight – the students would be passive observers hearing about something that already happened. I could take it a step further and give each group a pre-written scenario – a vast improvement because they would have to think critically about their solution. However, my solution took this emotional involvement a bit further, letting each group randomly generate their own unique scenario, with random benefits and pitfalls. I couldn’t predict the outcome, therefore every situation was unique and posed it’s own challenges (to the class, and to me).

After 40 minutes of lecture where I presented incident response team concepts and methodology, I let each of my student groups  generate a company faced with multiple security problems. Each team was given two polyhedral dice (20 and 6 sided). They were provided some brief instructions:

Exercise 1: Our Saga Begins                         Building an Incident Response Team

INSTRUCTIONS: You will be completing these exercises as a small group. Every group’s scenario will be a
little different based on the roll of the polyhedral dice you’ve been provided. Fill in the blanks with your
random dice roll, and then complete the exercises. Some groups will be ‘luckier’ than others, but that’s how the cookie crumbles. Every group will share their situation and solution.

And some static background, for the sake of brevity:

Due to your stellar reputation in Incident Response, your consulting firm has been hired by Renraku, a
4500 employee global company, to design their very first dedicated Incident Response team. They’ve
been having an increasing number of security incidents over the past year and they’ve relied on outside
contractors and vendors to help investigate and resolve them. They currently only have a Security
Operations Center (SOC) that does some basic log monitoring, patching, and malware remediation. The
CISO Mr. Lanier provides the following specifications:

–  The IR team will respond 24/7/365 with a projected staff of 10 people (on an on-call rotation).
–  They will respond to physical and digital security incidents
–  IR team will collaborate with members of the HR, legal, loss prevention, and physical security teams.
–  On detection of incidents, the SOC will normally be the ones to page out the Incident Response team.

I then let them roll the dice to determine some key aspects of the incident response scenario:

Roll [D6] _______. This will reflect the industry that Renraku focuses on (for the rest of this course):
(1) Retail Stores
(2) Hospitals
(3) Financial Investments
(4) Defense Contracting
(5) News Media
(6) Oil, Gas, and Electric

Roll [D20] ___________. This is how many major security incidents Renraku has been faced with in the
12 months. If you rolled over a 12, it means they were dealing with more than one incident at once (and
may have to again).

Roll [D20] ___________.   The number of months it took Renraku to detect their last major compromise.

Roll [D20] ___________.   The number of countries that Renraku operates offices in.

Roll [D20] ___________.   The number of subsidiaries with different system configurations and software
that have unrestricted connections to Renraku’s internal network.

This posed an interesting challenge because not everybody in the class had played a roleplaying game with polyhedral dice, before. Having small groups helped with this, as the people who enjoyed tabletop gaming immediately latched on and took their dice rolls very seriously!

I knew there would be stumbling points in presenting the course, and did my best to anticipate them. I predicted that some teams would be in very good situations and others in very untenable ones, so I was very careful to weight each dice roll to keep them in realistic ranges. In practice, this worked fairly well, but in the future I will be widening this range slightly because none of the groups were in a truly difficult staffing position on their mock incident response teams. I was also worried that some of the companies would turn out too identical, but fortunately my statistical math was (surprisingly) good and of my seven groups, only two ended up very similar in industry and security issues. This is something to consider carefully when developing a new scenario: what are the worst and best case scenarios that can occur?

The biggest issue I ran into ended up being time. This was both a bad and a good problem to have – the groups had in depth, occasionally heated discussions about their companies. I was trying to engage them emotionally and I think I succeeded to an extent because of this. I actually had to stop a couple of the exercises early to stay near the timeframes I had set for each exercise. In the future, I’ll be trimming down lecture a bit more and making the exercise constraints more clear. I stated at the beginning of the course that none of the exercises solutions needed to be technical in nature, but some of the groups worked out very interesting technical solutions to the problems.

Another problem I faced was rewarding achievement. When I present this course again, I’ll have to clearly establish criteria for which group wins each exercise (and wins fantastic geeky swag)! All of the groups had great solutions and creative ideas, and I felt very on-the-spot trying to choose a winner quickly.

During the class I learned very quickly that camping it up and interjecting roleplay kept it fun. I played the role of ‘GM’ throughout the exercises, occasionally rolling a D20 to see if the companies were set up in hostile countries or involved in embarrassing data breaches. I was careful to start this with groups that were already having a good time and playing with the scenario – the group that rolled miserably on their Oil & Gas company network and made up a great story as to why was repeatedly dogged by hacktivists! This really kept me on my toes. My recommendation to others less familiar with off-the-cuff roleplaying might be to write down some injects in advance.

All in all, I highly recommend this method for teaching the creative thinking and logical reasoning skills that are so desperately needed in incident response. Presenting a randomized scenario made each team care a bit more about the company they were representing, and introduced a large number of unpredictable scenarios. My students were engaged throughout the class and I got some very positive feedback afterwards.

I’m excited to continue development of my gamified Incident Response course through the year, and I’m happy to present it at cons as I’m available, or help you set up your own program. You can find my slides, worksheets, and sample scenarios on Google Docs here – I only ask for credit if you use my work directly. Enjoy!

What is ‘DFIR’? And how do ‘Digital Forensics’ roles vary?

I had a discussion today with a particular charming infosec pop star about what differentiates ‘DFIR‘ from other infosec job roles and how it relates to them. This is a question I get asked a lot by ladies and gents interested in making a jump into information security careers, so let’s have a brief discussion on what these forensicator jobs tend to do in your average working environment.

Now, you may be generally familiar with digital forensics – the exciting science of taking all manner of digital ^stuff^, and finding out what it’s done, when it was done, and who did it. Seen weekly on your average episode of CSI or NCIS… it is nothing like CSI or NCIS.

It’s usually not too much like what’s taught in ye olde average Forensics degree program. Not judging.

So first, what is this ‘digital stuff’ that we can do forensics on? Well, the obvious use case is a hard drive. Take it out of a computer. and find out everything that’s happened on that computer. When was the computer turned on, and who logged in? What programs did they start, and what did they do in those programs? Did they do any internet browsing? In the 1990’s and early 2000’s, proving those things in court were a large portion of the field. Modern digital forensics goes way beyond that. We’re not just concerned with PC hard drives. We’re concerned with anything that runs on 1’s and 0’s, from cars, to hospital equipment, to USB drives, to cameras. That’s the ‘internet of things’, friends. It can all contain digital evidence. A car GPS can tell us where it’s navigated to for weeks. A camera can tell us where every photo was taken. A hospital lab machine can tell us which USB drive connected contained malware, and from where.

“But Lesley, who wants that evidence? Abby from NCIS, and her beautiful beautiful pigtails, no?” Yes, and no. As appreciative as I am of Ms. Sciuto’s fashion sense, law enforcement is only one small measure of modern forensics professions. We can generally break down forensics on all these devices into two fields – e-discovery, and Digital Forensics and Incident Response (DFIR). E-Discovery is the legal side of forensics – in a broad sense the person being investigated is the case, and digital forensics tools and procedures are being used to support a case involving them. DFIR is more the infosec side of forensics- the digital system is the case, meaning instead of our main objective being investigating a external case, the digital device is being investigated. Examples of this are all types of security incidents, from data breaches to malware. Some forensics professionals do both types of cases, and others just do one or the other.

E-Discovery professionals tend to interface the most with legal and law enforcement agencies. Many e-discovery professionals have a legal background, but that is certainly not all inclusive. These are the guys and girls who are reading the emails you deleted. DFIR professionals tend to work as part of the blue team, working as parts of SOCs or CSIRTs or with malware analysts. They often have security operations center backgrounds – again, not all inclusive by any means.

Both of these jobs involve similar tools. Both types of investigators need tools to sift through deleted files on hard drives, browser caches, memory, and Windows registries (for similar and different reasons). The commercial products used by both overlap, although memory forensics is still often a DFIR specific field, and preserving a court admissible chain of custody oft remains the realm of e-discovery.. We see a lot of Guidance, FTK, and Oxygen tools heavy in the market. Obviously, both require quite specialized tools as well. Malware hides differently than human beings do.

“So, Lesley, what is the biggest myth about digital forensics?” Well, first of all, it is not Abby’s pigtails, because I rock fishnet. I would have to say that the biggest exaggeration is steganography. Its become a running gag that every time I find a person who wants to study or is studying forensics, their first case study will be some sort of steganography. If you don’t know what that is, you should read an article or two, as it is quite intellectually interesting. Unfortunately, it is a rare case that actually involves the hiding of data in this manner. The truth is, networks tend to be so insecure that such drastic methods are not usually necessary outside of certain uncouth communities. I spend a great deal more time recovering wholly undeleted data from memory and slack space on hard drives. I do wish that forensics degree programs spent a lot more time on memory forensics with products such as Volatility and Mandiant Redline, as it is frequently critical.

The second biggest myth is that ‘porn mode’ has any impact at all on me being able to see what you’ve browsed in the last several weeks. It rarely does. Not judging, again.

So there we have it. Foreniscs, and it’s variations in a nutshell. If you would like to know more, please feel free to tweet or message me. I am as always, happy to respond.

Lesley’s Rules of SOC

I see a lot of the same errors made repeatedly as organizations stand up Security Operations. They not only result in lost time and money, but often result in breaches and malware outbreaks. I tweeted these out of frustration quite some time ago and I’ve since been repeatedly asked for a blog post condensing and elaborating on them. So, without further ado, here are Lesley’s Rules of SOC, in their unabridged form. Enjoy!

  1. You can’t secure anything if you don’t know what you’re securing. 

    Step one in designing and planning a SOC should be identifying high value targets in your organization, and who wants to steal or deface them. This basic risk and threat analysis shows you where to place sensors, what hours you should be staffed in what regions, what types of skill and talent you need on your team, and what your Incident Response plan might need to include,

  2. If you’re securing and monitoring one area really well and ignoring another, you’re really not securing anything. 

    An unfortunate flaw in we as an infosec community is that we often get distracted by the newest, coolest exploit. The vast majority of breaches and compromises don’t involve a cool exploit at all. They involve unpatched systems, untrained employees, and weak credentials. Unfortunately, I often see organizations spending immense time on their crown jewel systems like their domain controllers, and very little paid to their workstations or test systems. All an attacker needs to be in a network is a single vulnerable system from which he or she can move laterally to other devices (see the Target breach). I also see people following the letter of the law in PCI compliance, ignoring all the software and human practices beyond this insufficient box.

  3. You can buy the shiniest magic box, but if its not monitored, updated, and maintained with your input, you’re not doing security. 

    Security is a huge growth market, and vendors get better and better at selling solutions to executives with every newsworthy data breach. A lot of ‘cybersecurity’ solutions are now being sold as a product in a box – ‘install our appliances on your network and become secure’, This is simply not the case. Vendor solutions vary vastly in quality and upkeep. All of this is moot if the devices are placed in illogical places in the network, so that the devices can’t see inbound or outbound internet traffic, or host to host traffic. Even with a sales engineer providing product initial setup, a plan must be developed for the devices to be patched and updated. Who will troubleshoot the devices if they fail? And finally, their output must be monitored by somebody who understands the output. I’m constantly appalled by the poor documentations big vendors provide for the signatures produced by their product. Blocking alone is not adequate. Who is attacking and what is the attack?

  4. If your executives aren’t at the head of your InfoSec initiatives, they’re probably clicking on phishing emails. 

    I think this is pretty self explanatory. Security is not an initiative that can be ‘tacked on’ at a low level in an organization. To get the support and response needed to respond to incidents and prevent compromise, the SOC team must have a fast line to their organization’s executives in an emergency. 

  5. Defense in Depth, mother##%er. Your firewall isn’t stopping phishing, zero days, or port 443. 

    I constantly hear organizations (and students, and engineers) bragging about their firewall configs. This is tone deaf and obsolete thinking. Firewalls, even next generation firewalls that operate at layer 7, can only do so much. As I’ve said previously, exploits from outside to inside networks are not the #1 way that major breaches are occurring. All it takes is one employee clicking yes to security prompts on a phishing message or compromised website to have malware resident on a host inside their network. The command and control traffic from that host can take nigh infinite forms, many of which won’t be caught by a firewall without specific threat intelligence. You can’t block port 80 or 443 at the firewall in most any environment, and that’s all that’s really needed for an attacker to remote control a system. So you have to add layers of detection that have more control and visibility. such as HIDS, internal IDS, and system level restrictions. 

  6. There are a lot of things that log besides your firewall and antivirus. 

    I wrote a post on this a while back listing a bunch. The thing that horrifies me more than SOCs that don’t have a decent SIEM or log aggregation solution are the ones that only monitor their antivirus console and firewall. So many network devices and systems can provide security logs. Are you looking at authentication or change logs? DNS requests? Email? 

  7. Good security analysts and responders are hard to find. Educate, motivate, and compensate yours. 

    Or you will lose them just as they are becoming experienced. Our field has almost a 0% unemployment rate. 

  8. Make good connections everywhere in your organization. People will know who to report security incidents to, and you’ll know who to call when they do. 

    There’s often a personality and culture clash between infosec people and the rest of the business. This is really dangerous. We are ultimately just another agency supporting the business and business goals. All of our cases involve other units in or organization to some extent or another. 

  9. If you don’t have some kind of Wiki or KB with processes, contact info, and lessons learned, you’re doing it wrong. 

    I can’t believe I have to say this because it’s true of almost any scientific or technical field. If you don’t write down what you did and how you did it, the next person who comes along will have to spend the time and effort to recreate your steps and potentially make the same mistakes. This also means everybody on your team needs to be able to make notes and comment on processes, not just one gatekeeper. 

  10. You can’t do everything simultaneously. Identify and triage your security issues and tackle one project at a time. 

    Plenty of the horror stories I hear from security operations centers in their early stages involve taking on too much at once – especially without the guidance of a project manager. These teams drop everything because they can’t do it all simultaneously. We have the unfortunate tendency to be ideas people without organizing the projects and tasks we develop into structured projects.

  11. Threat Intelligence is not a buzzword and does not center around APTs. Have good feeds of new malware indicators. 

    Yes, there are predatory companies selling threat intelligence feeds with little or no value (or ones that consist entirely of otherwise free data). The peril in discounting threat intelligence is that signature based malware and threat detection is becoming less valuable every day. Every sample of the same malware campaign can look different due to polymorphism, and command and control mechanisms have gotten complex enough that traffic can change drastically. We are forced, at this point, to start looking in a more sophisticated way at who is attacking and how they operate to predict what they will do next. The includes things from identifying domains resolving to a set of IPs to sophisticated intelligence analysis. How far you take threat intelligence depends on time, funding, and industry, but every organization should be making it a part of their security plan.

  12. if your employees have to DM me for help with their basic SIEM / log aggregation, you’re failing at training. 

    Happens all the time, folks. I see a lot of good people at organizations with terrible training cultures. Make sure everybody has a level of basic knowledge from the start, and isn’t so intimidated in asking for help that he or she feels forced to go outside your organization. 

  13. Team build, and don’t exclude. The SOC that plays well will respond well together and knows their members’ strengths and shortfalls. 

    Prototypical hacker culture, while an absolute blast, is not for everyone. I’ve seen people shamed out of infosec for the most bizarre reasons – the fact is that some people don’t drink alcohol, or want to go to cons, or think Cards Against Humanity is appropriate. Yes, we are generally intelligent people and we can be rather eccentric. That doesn’t mean that people who find these things unpleasant don’t have skills and knowledge to contribute. Accept that they don’t have the same interests and move on without badgering. It’s their personal choice. When you plan your teambuilding activities, try to make them inclusive – people with kids might not be able to hang out at the bar at midnight.

  14. If you seek hires do it in range of places. Grads, veterans, exploit researchers, and more all may have different stuff to offer. 

    I see a lot of organizations with a relationship with a infosec group or university that only recruit from that specific pool. As with lack of genetic diversity, this provides no advancement or innovation. There are tons of places to find interesting perspectives on infosec from well educated candidates. It’s important to bring fresh ideas and perspective into your team.

  15. if your ticketing system doesn’t work in a security context, get your own dang ticketing system and forward. 

    There are two main reasons that you shouldn’t be using the same ticketing system for security cases that your IT department uses for everyday help desk operations. The first is security – there is no reason that your IT contractors or non-IT staff in general should be able to see the details of sensitive cases, even by an error in permissions. This also includes their accounts, should they become compromised. The second is that these ticketing systems are not designed with security incidents in mind. A security incident case management platform should do Critical things like store malware samples safely, provide court admissible records of evidence hashes and case notes, and integrate with SIEM or log aggregation solutions. If your ticketing solution is not doing these basic functions, it’s high time to consider a separate platform.

  16. DO virtualize your malware analysis. DON’T virtualize your security applications unless the vendor says how to. 

    Virtualization software is critical for lots of reasons in infosec – from setting up malware analysis labs to CTFs to honeypots. It is not appropriate for all security applications and solutions. Most organizations are heavily pushing virtualization as a cost saving initiative, but be very cautious when presuming all resource intensive and highly specialized security tools will function alike when virtualized.

whois hacks4pancakes

Hi, I’m Lesley. It’s very nice to meet you. You might know me better as Hacks4Pancakes. I think it is high time I introduce myself.

I’m one of these index and I do this for a living:

Photo: Craig SjodinABC Studios ©2007 ABC Studios. All Rights Reserved.OK, not quite, it’s actually more like:indexwith a lot of tardisme

I have been working professionally in Information Security for about 8 years, and have been working in IT for about 15 years, interrupted by stints I spent doing other interesting things like this:

lesley 3

My current profession is leading a digital forensics and incident response team, which sounds exciting and glamorous but mostly means I get to stay up late watching loading bars pensively, and going through deleted internet browsing history looking for bad stuff and figuring out what malware did. It’s what I wanted to be when I grew up if I couldn’t be on the SWAT team, though, so I’m pretty happy.

I also do a lot of this:


I study three martial arts on a (very) dedicated basis and attend seminars as often as I can to gain exposure to other weapons and styles. I also teach firearms classes and enjoy some friendly pistol marksmanship competitions.

The rest of my not so exorbitant free time is spent going to infosec meetups, gaming, reading, meditating, and watching science fiction. I love going to science fiction conventions, and still enter costume competitions with my best friend. Last year I spent 6 hours airbrushing her grey.

I have lots of good friends who also do this:


OK, it’s really more like:


Which is still pretty damn cool.

A whole boatload of people follow me on here: index. I’m not exactly sure why, but I’m pretty sure it’s for my highly serious commentary on the current state of cybersecurity affairs.

So why am I blogging?

When I originally wanted to get into computer forensics, I called something like 30 police departments and colleges for advice, but nobody had heard of the field yet. Still others demanded I have exposure to highly specialized and expensive tools to gain an entry level job. It took years of hard work and a great network of friends in security for me to finally make it into the career I love. On the way, I found I’m pretty good at the sister field, Incident Response, which means organizing the efforts out how computer and computer networks were hacked, what was taken, and how to stop it from happening again. You’ll often see the fields combined and abbreviated as DFIR: Digital Forensics and Incident Response.

Anyway, my problematic experience breaking into infosec means that I always try to go out of my way to help people who are new to the field or interested in learning more about security. I speak regularly and infosec and non infosec conventions about hacking. I write security basics blogs and ebooks which are posted by my employer, as well as helping students interview for their first jobs in the field when I can. I am hoping the blog becomes a resource for more advanced infosec students and professionals who are trying to learn more about DFIR and how to implement associated programs.

I do hope you enjoy my blog and please feel free to let me know what you’d like me to discuss or assist with.

– Lesley

Excuse me I have fallen off the blog boat

A long time ago, in a galaxy far far away, I worked as a SQL developer for a ecommerce company in the 90’s. The commercial internet was relatively new and shiny, hacker culture was in full swing, and even slightly irritating gothy kids could get work in the dot com boom and go to parties straight out of the Matrix with pretty horrible rave music. It was there that I made my first real life connections in the Chicago hacker scene and went from a rather insular computer life to the exciting new uses for the internet.

A colleague approached my friends and I with a novel concept – we were going to start journaling on a private website, writing out our youthful angst and the various horrible things we did to Linux and Windows 9x. Of course, the term ‘blog’ had not been coined yet, and even ‘weblogs’ were pretty unknown. So, we wrote, and wrote. Insomuch I’m a bit glad this was long before the existence of web archiving and I’m a bit glad I can’t read my complaints about school and family. I remember one harrowing birthday where I wrote what seemed to me to be the most profound thing I had ever written, and lost power mid post. (This was also before the existence of drafts or autosave!)

I can’t recall when it all stopped. The dot com bust ruined the glamour of the internet that had no limits – the one that ran in dark rooms blasting Orbital on servers maintained by long haired Linux geeks from 2600.

Many years later, I occasionally considered returning to blogging. I wrote some articles, short stories, and regular infosec articles for my employers. But, I’d never considered until this point that I have anything worthwhile to blog to the community. The internet is full of blogs now. Billions of stories about everything from human rights to breakfast. An archive of an entire society and our human knowledge, (good, bad, and everywhere in between).

But the fact is, my lovely friends have pestered me about posting some stories, articles, and guides in longer form, so I’ve decided to start this blog to share mostly infosec related research and tools I’ve developed over the years. You can still find my regular security basics blogs at Motorola Solutions Fresh Ideas in Public Safety. I’ll use this as a platform to share more in depth resources as they come along.

Thank you for visiting and for your requests!