InfoSec Triads: Cost/time/functionality

Triad: Cost, Functionality, Time
Triad: Cost, Functionality, Time

Following InfoSanity’s recent (and unexplainable) focus on triads in previous posts is the relationship between cost, time and functionality. For the purpose of this discussion assume a scenario for introducing a new product/service or adding new capabilities to an existing service.
In an ideal world all projects would have enough resources and realistic timescales to develop all required functionality to the highest level of quality. However in the real world this is rarely achievable when working with external constraints. Therefore in any project compromises are inevitable.
The theory stands that with a given set of resources, only a finite amount of functionality can be developed. Therefore it stands to reason that additional functionality can be added to a project by increasing the length of the project or adding additional resources (although the Mythical Man Month and Dilbert may refute this simplistic theory).
Within ever tightening economic conditions and competition, in order to reduce costs and/or development and implementation time functionality is stripped from the service. As security is often seen by wider business as a nicety rather than a necessity, security features are commonly the first to be dropped, or the security of features still implemented is reduced.
Despite what infosec professionals (myself included) may like to think, reducing security to meet business or market drivers isn’t necessarily a bad thing. Providing that the benefit gained is proportionate to the additional risks introduced, and those risks are acceptable to the business and/or client. However, in the increasing world of regulatory compliance this can provide a false economy to a business as it is almost universally more costly in implement additional security on-top of an existing solution than it is to bake the required security into the design and development phases.
And if anyone tells you that a less secure solution is temporary and will be rectified at a later date… Don’t believe them 🙂
— Andrew Waite

I’ve been a bit lax in writing this post; around a month ago Miguel Jacq got in contact to let me know about a couple of errors he encountered when running InfoSanity’s with a small data set. Basically if your log file did not include any submissions, or was for a period shorter than 24hours the script would crash out, not the biggest problem as most will be working with larger data sets but annoying non the less.
Not only did Miguel let me know about the issues, he was also gracious enough to provide a fix, the updated script can be found here. An example of the script in action is below:

cat /opt/dionaea/var/log/dionaea.log| python
Statistics engine written by Andrew Waite –
Number of submissions: 84
Number of unique samples: 39
Number of unique source IPs: 65
First sample seen: 2010-06-08 08:25:39.569003
Last sample seen: 2010-06-21 15:24:37.105594
System Uptime: 13 days, 6:58:57.536591
Average daily submissions: 6
Most recent submissions:
2010-06-21 15:24:37.105594,, emulate://, 56b8047f0f50238b62fa386ef109174e
2010-06-21 15:18:08.347568,, tftp://, fd28c5e1c38caa35bf5e1987e6167f4c
2010-06-21 15:17:08.391267,, tftp://, bb39f29fad85db12d9cf7195da0e1bfe
2010-06-21 06:29:03.565988,, tftp://, fd28c5e1c38caa35bf5e1987e6167f4c
2010-06-20 23:34:15.967299,,, 094e2eae3644691711771699f4947536

— Andrew Waite

OWASP at Northumbria Uni – June 2010

June 16th marked the first time the Open Web Application Security Project’s (OWASP) Leeds/Northern Chapter ran an event at Northumbria University, meaning it was the first time I was able to attend. Jason Alexander started off events with a brief overview of OWASP and the projects the group is involved with.
ENISA Common Assurance Maturity Model (CAMM) Project
Colin Watson did a good job of explain the work he and others have been working on. The project have released two documents which Colid discussed, the Cloud Computing Risk Assessment[.pdf] and the Cloud Computing Information Assurance Framework[.pdf]. Don’t be put off by the focus on ‘Cloud’, whilst this was the focus and reasoning behind the work at the start of the project, the information and processes Colin describes could easily be related to any IT environment and at first glance seem to be well worth a read.
Open Source Security Myths
Next up David Anumudu gave a somewhat brave talk considering the audience discussing and (potentially) debunking the assumption that open source software is more secure than it’s closed source competitors. David picked on the now famouse phrase from The Cathedral and the Bazaar, ‘ Given enough eyeballs, all bugs are shallow’. David argues that while this is true and reasonable, it only works in practice if all the eyeballs have both the incentive and the skills to effectively audit the code for bugs, something is rarely discussed. A sited example of insecurities in prominent open source software was that of the MD6 hashing algorithm, intruced at Crypto 2008, where despite being designed and developed by a very clued up team still had a critical flaw in it’s implementation.
My ultimate take away from this talk was that software’s licensing model has no direct impact on the security and vulnerabilities of any codebase, only the development model and developers themselves have any real impact.
SSL/TLS – Just when you thought it was safe to return
Arron Finnon (Finux) gave a great presentation on vulnerabilities and weaknesses with the implementation of SSL protection. Arron argues that most problems with SSL are actually related to the implementation rather than methodology itself, and that despite the high profile of problems related to SSL most techies still don’t ‘get’ it; and most users, regardless of user awareness training will continue to blindly click through the cert warning prompts.
Several of Moxie Marlinspike’s tools were discussed, mainly SSLStrip and SSLSniff. I was aware of both tools, but hadn’t tried them out in my own lab yet, after Arron’s discussion of the problem and capabilities this is definitely something that I intend to rectify shortly. Especially when combined with other SSL issues, including the SSL renegotiation attack and the Null Prefix[.pdf] attack issues with SSL can be deadly to an environment.
Main takeaway from this talk was that SSL isn’t as secure as some would state, and that when planning to defend against the attack vectors we need to stop thinking ‘what if’ and start working towards ‘what when’.
AppSensor – Self aware web app
Colin Watson came back to the front to discuss the work currently being undertaken with the AppSensor project. The idea behind the project is to create web applications that are ‘self aware’ to a lesser extent enabling any user making ‘suspicious’ web requests to be limited or disconnected to limit the damage that they can cause to the target system, and works on the premise that the application can identify and react to malicious users in fewer connection requests than the user needs to find and exploit a vulnerability.
The identification comes from watching for a collection of red flags and tripwires built throughout the system, from simply looking for X number of failed log-in attempts to real-time trend analysis looking for an unusual increase in particular functionality requests. A lot of the potential indicators and trapped reminded me a lot of an old post on the Application Security Street Fighter blog, convering using honeytokens to identify malicious activity, which I’ve covered previously.
Overall I really enjoyed the event, I’m hoping that the Leeds/Northern OWASP chapter decide to run more events within Newcastle, but if not it’s convinced me that the events are worth the time and cost to travel down to the other locations. Always good to discuss infosec topics face to face with some really knowledgeable people.
–Andrew Waite

InfoSec Triads: Security/Functionality/Ease-of-use

Triad: Security, Functionality, Ease of Use
Triad: Security, Functionality, Ease of Use

Following from an introduction of the C.I.A. Triangle another triangle is used to help explain the relationship between the concepts of security, functionality and ease of use. The use of a triangle is because an increase or decrease in any one of the factors will have an impact on the presence of the other two.
As an example, increasing the amount of functionality in an application will also increase the surface area that a malicious user can attack when attempting to find an exploitable weakness.
The trade-off between security and ease of use is commonly encountered in the real world, and often causes friction between users and those responsible for maintaining security. Microsoft had long been targetted by the security community for allowing everyday users to operate the system with administrative or system level permissions, which resulted in any exploit targeting a userland application was immediately given access with full rights. When Microsoft tried to limit this functionality by forcing users to specifically request elevated privilages via User Access Control (UAC) there were high number of complaints from users who weren’t happy with the extra actions required to complete tasks. As a result many instructions and guides were created to teach users how to disable the UAC functionality; increasing the ease with use and decreasing the steps needed to perform some tasks, but at the expense of disabling an improved security system.
A recent blog post discussing the security of windows operating system states, quite colorfully that:

Windows is an open cesspool to anyone developing applications. Developers can store information anywhere in the registry and store executable components anywhere in the file system – this includes overwriting existing registry entries and files. They can also write “hooks” to intercept, monitor and replace operating system calls to do fancy things. While all of this is great from a functionality standpoint, it’s also the main reason why Windows can never be secured.

Leaving the bias and hyperbole of the above, rightly or wrongly developers are able to write to the filesystem, registry and hook API calls in order to provide the functionality expected and requested by end users. From this standpoint no functional operating system will never be 100% secure, what every system and ultimately user must settle on a compromise between acceptable functionality and usability, and acceptable security.
I’d been looking for this Dilbert strip when writing the post, just came across it now, enoy:

Dilbert - Security trade-off


Breaking into the loop

For those that don’t know, the first run of the InfoSec Mentors programme got off the ground this week. My mentee, Jacob (@BiosShadow), has released his first blog post, Being out of the Loop, since we were paired together and it has struck a chord with my own experience with similar problems and got me thinking at the same time.
To sum up Jacob’s post he his frustrated that there is no active infosec community within a reasonable distance of his location. I can relate to this sentiment; when beginning the slow road towards an infosec career, before I was even aware a legitimate career in the field were possible, my own interactions and learning opportunities were limited to reading books or online articles. The online infosec community is, in my opinion, great; and the debates, relationships and friendships that can be developed is something that I don’t think is found in any other industry, but you can’t fully replace the benefits from a face to face meeting.
One of the early mistakes I made was assuming that information security and computer threats were only of interest to those solely focused on information security. I’ve since discovered that different aspects of infosec can be of interest or concern to anyone in the IT or business arenas, and I’ve been involved in some interesting discussions and debates on information security with some very intelligent people at some of my areas flourishing IT user groups whose focus isn’t infosec specific. It was one of these groups, SuperMondays, that provided my first public speaking opportunity and despite my topic, honeypots, being quite specialist I believe the talk was very well recieved.
Since first finding SuperMondays I have continued to discover a great and vibrant IT community in my region (NorthEast England), and I’m continually surprised when I continue to stumble upon other groups in the area like the Northern UK Security Group (must find time to travel across to Manchester) and I am eagerly awaiting the local-ish OWASP chapter from Leeds heads North to Northumbria University next Wednesday.
If you feel the same frustations as Jacob and myself (and others), throw a message out on twitter or your blog etc. letting people know who and where you are. You just might be surprised to find others in your area with the same problems.
For my part: If you’re in the North East of England (or general area) get in touch and let me know, always keen to discuss information security with anyone willing to listen.
–Andrew Waite

InfoSec Triads: C.I.A.

Triad: Confidentiality, Integrity, Availability
Triad: Confidentiality, Integrity, Availability

Information security is a far reaching and often all encompassing topic, but at it’s core information security and the protection of digital assets can be reduced to three central attributes. These are Confidentiality, Integrity and Availability; often referred to as the CIA triangle (not to be confused with the US’ Central Intelligence Agency).
Each factor provides a different and complementary protection to data and all three must be sufficiently preserved to maintain the useful of the information and information systems that are being protected.
Maintaining data’s confidentiality requires ensuring that only those users and/or systems authorised to access the stored information are able to access the protected data.
As a result this aspect is often what first comes to someone’s mind when thinking about information security, the act of preventing those that shouldn’t be able to access the data from doing so. Some of the most commonly understand security systems and processes fall into this category, for example requiring user authentication in the form of a password, or preventing remote access to a restricted resource with a firewall. Removing technology from the process, this is the equivilent of using a lock on the office filing cabinet.
Maintaining data integrity involves ensuring that the data remains correct, whilst in storage or transit, and that only authorised changes are made to the data.
At a highlevel data integrity can be protected using similar controls to those enforcing data confidentiality discussed above, if the data can only be accessed by those that are authorised to view and modify the data are able to access it in the first place then data integrity must be enforced. Unfortunately this is only part of the story as it only protects against the data’s integrity being compromised by a malicious third part. Data integrity can also be compromised by an authorised user changing the data in error, a program handling the data could contain a programming or logic flaw resulting in it changing the data in a way other than desired, or a hardware error could result in the stored data becoming corrupt.
Hashing algorithms like MD5 or SHA1 can be used to determine if the contents of a file has been changed, but this cannot determine if the file has been changed correctly. This highlights one of the key problems within the realm of information security; while data integrity falls under the remit of security there are many different factors, and in the business world many different individuals and/or departments, that can have a direct impact on data integrity; and the overall protection is only as strong as the weakest link.
Maintaining availability of both systems and information is crucial for most IT professionals to continue in gainful employment. As a result a lot of tasks geared towards ensuring systems availability are already incorporated into most business practices, including frequent backups and maintaining standby systems to replace production units in the event of a failure.
Availability of data can be attacked by a malicious user, application or script deleting the data itself; a newer form of attack, ransomware, follows a general trend of monetizing computer attacks involves preventing the legitimate users of the data by cryptographically protecting the data with a key know only to the malicious parties, who then attempt to extort money from the victim in return for the kep to unlock the data.
Alternatively denial of service (DoS) attacks prevent legitimate use of a service by utilising all resources of the server. Like ransomware DoS attacks can be monetized by a malicious party, either before the incident with the potential victim required to pay-up to prevent the attack from occuring in the first incident or being forced to pay to stop an incident that is already in place. Online betting sites were among the first of those businesses to be threatened in this way. The IACIS has a good paper on the topic of cyberextortion [pdf].
— Andrew Waite

Amun statistics

Amun has been running away quite happily in my lab since initial install. From a statistic perspective my wor has been made really easy as Miguel Cabrerizo has previously taken one of the InfoSanity statistic scripts written for Nepenthes and Dionaea and adapted it to parse Amun’s submission.log files.
Results generated from the script in my environment are below, if you’re wanting to get an overview of submissions from another Amun sensor the script has been uploaded alongside the other InfoSanity resources and is available here.

~$ cat /opt/amun/logs/submissions.log* | ./
Statistics engine written by Andrew Waite ( modified by Miguel Cabrerizo (
Number of submissions      : 25
Number of unique samples   : 25
Number of unique source IPs: 18
Origin of the malware:
Ukraine :     1
None :     7
Poland :     2
Romania :     1
United States :     8
Russian Federation :     2
Hungary :     1
Norway :     1
Bulgaria :     2
Vulnerabilities exploited:
MS08067 :    13
DCOM :    12
Most recent submissions:
2010-05-31, 11:37:22,, 63.exe, acf5c09d547417fe53c163ec09199cab, MS08067
2010-05-30, 19:23:09,, 63.exe, 89b578839f1c39f79d48e5f9e70b5e2f, MS08067
2010-05-28, 10:27:03,, 63.exe, f7c4f677218070ab52d422b3c018a4ba, MS08067
2010-05-27, 16:23:14,, ssms.exe, 1f8a826b2ae94daa78f6542ad4ef173b, DCOM
2010-05-24, 19:46:35,, 63.exe, 53979f1820886f089a75689ed15ecf6e, MS08067

A comment on a recent post asked for a comparison between different honeypots, while this is far from conclusive and only focuses on a single aspect of the technologies one of InfoSanity’s Nepenthes sensors ‘saw’ more attacks in the last 24hrs than my Amun installation did in the almost three weeks shown above. As both are running within the same, small, IP allocation I think I’m safe in assuming that one IP isn’t actually receiving a disproportionate level of interest from the badguys and bots that are out there.
— Andrew Waite

Starting with Amun

No single technology can do or handle every situation; the same holds true with honeypot sensors which is why I’m always interested in finding new systems to add to my environment. I’d had Amun on my list of potentials for a while, but after reading a short blog post by Miguel Cabrerizo that suggested install and setup was relatively quick and painless, it got moved up the to-do list.
As suggested the install was quick and easy, with no real problems. Since being installed the system has done what it says on the tin, emulating vulnerabilities and logging interaction with attacking sources. The sensor has been active for around 5 days and has collected 14 unique malware samples to date. Whilst not immediately being indicative of any comparison, three of these samples have not also been ensnared by Nepenthes or Dionaea sensors running within the same IP space.
The Amun log directory shows some interesting information, with logging being split between several different files. From initial results there is some interesting information collected by the system. One aspect of the logging that I’m unsure if I like is that Amun rotates it’s log files on a daily basis, so far this is resulting in my log directory getting cluttered with rotated files. For the curious available log files are:

  • amun_request_handler.log
  • amun_server.log
  • download.log
  • exploits.log
  • logging.log
  • shellcode_manager.log
  • shellemulator.log
  • submissions.log
  • successfull_downloads.log
  • unknown_downloads.log
  • vulnerabilities.log

Going forward there are a number of installation and configurations options available from Amun that I intend to experiment with; high up this list is the ability to log to a MySQL database, I’m hoping that this will provide both a convenient and powerful way to search and analyse the information collected by the sensor. In the meantime Miguel has extended one of InfoSanity’s submission_stats to gather similar statistics from Amun sensors, Miguel’s work is available here.
— Andrew Waite

amun01:/opt/amun# ls -l malware/md5sum/
total 2512
-rw-r–r– 1 root root 155648 2010-05-13 10:53 0cc3c16497214997a9aca72e387c9d9b.bin
-rw-r–r– 1 root root 444416 2010-05-12 15:43 146d61fca77d748f5a5ecff53afd30e4.bin
-rw-r–r– 1 root root 158720 2010-05-11 07:43 14a09a48ad23fe0ea5a180bee8cb750a.bin
-rw-r–r– 1 root root 159744 2010-05-11 00:29 1d419d615dbe5a238bbaa569b3829a23.bin
-rw-r–r– 1 root root 153600 2010-05-15 13:41 53098aa3e420a1be0a5e6a992dc30f3b.bin
-rw-r–r– 1 root root 176128 2010-05-10 23:35 5a951d625eb10b900eb7001892edfa77.bin
-rw-r–r– 1 root root 159744 2010-05-13 19:16 6366b14ed66bf79d6ece8ed8cb116838.bin
-rw-r–r– 1 root root 153600 2010-05-12 13:36 98eb0fdadf8a403c013a8b1882ec986d.bin
-rw-r–r– 1 root root 172032 2010-05-13 06:22 9b1bec8e5fbc9696c60422a031147d07.bin
-rw-r–r– 1 root root 159744 2010-05-13 19:16 a7b197e90b2c5d63b19dfb4797ef7710.bin
-rw-r–r– 1 root root 147456 2010-05-14 07:04 b407982b9eea8c8af3ff4f52ee71c44a.bin
-rw-r–r– 1 root root 147456 2010-05-11 07:09 b786ad96a1dfb330e05595e4657d8a61.bin
-rw-r–r– 1 root root 160768 2010-05-12 14:46 bb39f29fad85db12d9cf7195da0e1bfe.bin
-rw-r–r– 1 root root 152576 2010-05-11 00:00 fd28c5e1c38caa35bf5e1987e6167f4c.bin

Book Review: 7 Deadliest Web Application Attacks

A while ago I was offered an excellent opportunity to read and review Mike Shema’s contribution to Syngress’s Seven Deadliest series focused on web application security. My first impression was very positive, and now I’ve had a chance to get my hands on the finished product I haven’t been disappointed.
As with the rest of the Seven Deadliest series the book is broken down into sever chapters, each focusing on a key attack vector. Covered in Web Application Attacks is:

  1. Cross-Site Scripting (XSS)
  2. Cross-Site Request Forgery (CSRF)
  3. SQL Injection
  4. Server Misconfiguration and Predictable Pages
  5. Breaking Authentication Schemes
  6. Logic Attacks
  7. Malware and Browser Attacks

I’ll be the first to admit that web application security isn’t my forte. Rather than let that put me off this was the appeal of the Seven Deadliest series, given the target topic the books aim is to succinctly cover the core issues and let the reader quickly get to grips with the subject material. Shema does this brilliantly; before I reading the book I (thought I) was comfortable with my understanding of web application security issues, after reading I’m now confident in both my theoretical understanding and, crucially, the technical implementation of the attack vectors discussed.
While the material is accessible to a new comer to web application security Shema wasn’t able to cover all subjects touched on during the book. For example, character encoding sets are discussed quite heavily during the cross-site scripting, but isn’t explained indepth at a low level. As a result, what a reader is able to take away from the book will likely be dependent on the experience and knowledge that the reader is able to bring to the material. In my case I was more comfortable with the chapters covering server misconfiguration (chapter 4) and malware (chapter 7).
After re-reading the material I would recommend this book to anyone that deals with web sites in anyway (that’s you), especially considering the price of the Severn Deadliest books. I’d also take a look at the rest of the series, covering:

— Andrew Waite
(oh, and if you won’t take my word for it, pay attention to the recommendation on the back….)

“The threats highlighted should be understood by Web developers, administrators, and general users alike. If you use the Web in any way then this should be on your bookshelf. In addition to detailing the threat Shema also provides countermeasures to minimize or remove the risk, but be warned; you may never look at a Web site in the same way again.”
Andrew Waite, Security Researcher, InfoSanity Research

Gain and maintain passion for infosec

I’ve had this post in the back of my mind for a while, but have held back as it is a quite a personal topic. When talking to anyone working in infosec one aspect remains constant from the rockstars at the top of the media game, the guys in the trenches or the newbies looking for a break; that constant is passion. Ultimately passion is what makes the difference between a job and a career, and in a world with the extra curricular requirements, continued professional development and somewhat crazy work hours that are related to the infosec world passion can be easy to lose and the daily grind results in the infamous burn-out. This makes it really important to have a few ways to remind you why you do what you do.
Looking back it’s easy to identify moments of my life that resulted in an interest for information security, even if the consequences weren’t obvious at the time.
Hackers (yes, the film)
Okay, I’ll come out of the closet on this one. When I rented the film this was my first introduction to the ideas of information security and the world of hacking. No, the film isn’t completely accurate, but what do you expect from Hollywood? What the film did do was start a burning desire to learn more, and as a kid geek who didn’t like the idea of being able to pull Miss Jolie with a laptop and elite skillz? As a result I spent the next few years Googling (OK, searching, Google wasn’t around at the time) hacking and reading any number of ‘how to start hacking’ files. Every now and then I still take the DVD from the box and re-watch the film that, for me, started it all. Hack-the-planet…
While this game was causing controversy at the time it was responsible for my learning computer basics and, in hindsight, the first time I circumvented access controls. The story is thus:
One Christmas (I was 8 ) my family got our first Windows PC (BBC Micro B with tape drive prior to this), after playing around and gaining my MCSE (Minesweeper Champion and Solitaire Expert) I found the icon for this thing called DooM on the desktop, and it was good. When parents spotted me playing it and reacted to the media controversy and removed the game (well the shortcut), a while later I’d found my way around an MS-DOS shell and was executing doom.exe from commandline. This lasted a couple of weeks before I was spotted again; after I was ‘persuaded’ to explain how I was still playing I had to teach my parents how to actually delete programs. Which did nothing but provide the opportunity for me to pick my first lock to get the install floppies from the disk box, but that’s another story.
Where Wizards Stay Up Late
One of many hacking related books I ended up reading in my initial search for information was Where Wizards Stay Up Late. If you’ve not read it the book documents the history of the internet, from the early days of DARPA onwards. For me this book provided the belief that computers could be a valid career path and contrary to my teacher’s belief at the time, not just something that kids play with.  All self-respecting geeks should know the history of their craft and the people that made it possible, so if the names Licklider, Larry Roberts, Frank Heart, Honeywell or BBN mean nothing to you I strongly recommend that you pick a copy of the book up.
Ethical Hacker Network
EH-Net was my first introduction to actually communicating with others doing infosec in the real world. The forums are an excellent source of information, discussion and support, and unlike many ‘hacker’ forums newbies and outsiders will be welcomed and supported as they find their feet rather than being ridiculed and ignored for asking ‘stupid’ questions. The support and discussions I received when I first became an active member of the forums gave me the belief and confidence that I could make an information security career a possibility, and I’ve made some great friends and contacts as a result. My biggest regret at the moment is that I don’t have enough time to be anywhere near as active in the forums as I once was, although I do intend to change this.
The best individual resource on EH-Net that I found for gaining and maintaining my passion for an infosec career is Don’s presentation DIY Career in Ethical Hacking. The slides and audio are here, I strongly suggest you take an hour to listen to the advice Don shares. In my case when I first heard the talk I took Don’s advice and had a serious look at my career and where I wanted to be in a few years; as a result I registered a week later. I still listen to the audio every 6-12 months to ensure I can stay on track. Thanks Don 😀
Conscience of a Hacker (Hackers Manifesto)
Possibly on of the best known piece of ‘hacker’ literature was released in Phrack back in 1986. Written by ‘The Mentor’ aka Loyd Blankenship it provides a unique and hard-hitting explanation of why some hackers are hackers, and for the typically introverted geek can help explain some very deep feelings to those that don’t understand. For a number of years I have owned a copy of the DVD recording of Blankenship’s presentation at 2600’s H2K2 conference and always find it inspirational, the story of a kid that showed his parent’s the article and stated ‘this is how I feel at school’ really highlights the power the article can have. Whether you’re already familiar with the article or haven’t encountered it before I’d suggest both reading the original and listening to Blankenship’s recitation and discussion of the article here[.mp3].
That’s my list; whenever the daily grind starts getting on top I can always count on one of the above resources to remind me why I want a career in infosec, or more importantly why I want to turn my hobby and passion into a career.
If you’ve got similar stories, or additional inspirational resources to share I’d love hear them.
— Andrew Waite