My Experience in an Isolation Tank

Note: I will never endorse a product or promote a product or service unless I have used it, or believe that it is a product worth trying. When I decided to try sensory deprivation, several of my friends and family wanted to know more about it, so I decided to write this blog post rather than tell the same story repeatedly.

About two weeks ago my brother in law called and told us about a new place that opened in Gas Town called the Float House. After discussing it briefly, I decided to give it a try even though I suffer from claustrophobia. This morning I spent approximately 80 minutes in the “float tank”, which is a much more friendly sounding name than “sensory deprivation tank” or “isolation tank”.

The process was pretty straightforward; after missing my first appointment due to a surprise meeting, I showed up this morning at 7:45 for my appointment. On arrival I signed the typical “if something goes horribly wrong, we weren’t responsible” waiver (this is not unusual, if you have visited any treatment place, such as chiropractic, massage, or physiotherapy, they get you to sign similar forms). You are strongly encouraged to use the rest-room, then take a shower at a neutral temperature to clean yourself before entering the tank. Entering the tank was super simple, and there is no clasp or lock on the door (to be honest, if there was, I may not have been able to get in). I didn’t get the dimensions of the tank, but I expect that it is approximately 8 feet in length, and 3-4 feet in height as I could stretch my arms or my legs lying down, but not both, and I could sit up comfortably in the tank.

Entering the tank was interesting because with one foot in the water, it felt as natural as stepping into a pool or bath, but after the second foot was in, I could immediately sense the buoyancy provided by the saltwater. After spending a couple of moments getting used to the fact that I was lying in the tank, I closed the door. It was completely dark in the chamber, but I could hear more than I expected, with the combination of the ear plugs, and being in a closed space, inside of a much larger facility. I waited a few minutes to make sure I was actually hearing sounds and that they weren’t ‘ghost’ sounds that my mind was filling in because of the lack of noise, then lay down in the water again. It took me a couple of minutes to get comfortable with the buoyancy, but I can’t clearly speak to how long because my sense of time was completely gone fairly quickly. It was really interesting to experiment with how I could move in the water in a different way, for example, stretching out the way I do in bed, or actually relaxing my neck and allowing the surface of the water to form a pillow around my head.

There was another thing I noticed fairly quickly too. Despite living in an area of the world best describe as a temperate rain forest that gets it’s share of rain, and everyone else share as well, I am constantly dry and dehydrated. As a result, my skin is frequently dry to the point of cracking, especially on my hands(I haven’t been diagnosed with any issues, and it is not irritating enough to invest significant time or effort beyond skin lotion). Seconds after entering the water I felt a slight sting in every scrape, scratch and crack in my skin (there are a few as I have been doing yard work and other stuff). It didn’t hurt, but it was definitely noticeable. It subsided after a few minutes, and was overall, probably better for my skin.

I was alone with my thoughts and feelings and eventually my awareness of my senses was altered as well. As with any environment, my senses began to adjust; I was able to focus on the sounds and feelings my body makes, including a regular clicking in my foot when it moved. I never noticed it before, but it became cringe-worthy after hearing it a few times. I made a mental note to get things in my foot checked out, and then tried to avoid moving my foot to prevent the distraction.

Some time into it, my leg muscle started spasming, which had the side effect of making me drift. The staff member helping me had explained that drifting can turn into a game of ping pong as you drift and deflect off of walls. So I did that for a few minutes, and was completely surprised a couple of times because I had the sensation of moving in one direction and would be drifting the opposite way. When that got boring I stabilized my self and settled for awhile.

After about 80 minutes I realized that I was finished, largely due to an overwhelming need to go to the washroom (listening to water has that effect on me :P). I climbed out, and against the advice of the tech, got some salt water in my eyes. In the Caribbean ocean the salt water feels pretty good. In an isolation tank, not so much. No harm done, but the stinging took about a minute to subside.

Fast forward 9 hours to when I am writing this post, and I feel like I have had a hard massage, and feel quite drained on top of it. Despite having a good shower after the fact, I had a nice coating of salt (I assume stuff that was absorbed into the pores). Overall, the experience was very good, and left me feeling extremely relaxed.

Since having done the float, I have had the chance to read up some more on the proposed health benefits of this activity, but I will leave others to do their own research. I will definitely try it again a couple of more times before I make decision on whether or not I think it is worth adding to the list of activities (or inactivities) that I partake in as part of de-stressing.

TLDR: went into an isolation tank, would do it again!

A note on fear and confrontation: I have a few phobias, none of which are crippling. Most are an annoyance, but I have tackled each one in turn, heights, crowds, spiders (I might be the only appsec person who hates spiders :P). Claustrophobia is a bad one for me. I won’t go into the reasons why, but I don’t like being in closed spaces, and even meeting rooms, or being in a room where there is a person blocking the exit is very disconcerting. Performing this activity is part of my ongoing effort to challenge myself to overcome fears and understand why I fear. I don’t recommend this as a regular course of activity for anyone who suffers from claustrophobia because this helped me understand that my fear of being confined has less to do with the space and more to do with feeling trapped or contained.

So you want to learn about ZAP? (BSides Seattle 2012)

On December 15th I will be giving a 2.5 hour training session at BSidesSeattle on how to use OWASP ZAP.

This is a training session, not a talk! I strongly recommend that you bring a computer that you can use to run ZAP as you will get much more out of it by trying things. The format for the session will be a series of 15 minute talks about something or other, followed by 15 minutes of testing and QA, which will speed up or slow down based on how many questions people ask.

There will also be a treatment of bugs such as Cross Site Scripting, SQL Injection, and a couple of others, time permitting.

I look forward to seeing everyone on Saturday!

Minion – Why, What, and How

Once we get where we want to with Minion, we will talk more about what we plan to do with it within Mozilla, both through a public webcast, and on the Mozilla Security blog, but right now we just aren’t ready for it. Instead, I will explain Minion, and lay out my personal goals for the project.

Why

At Mozilla I work with a team of really bright people who are working hard on some of the challenges of building secure software and managing the IT security related risks associated with a high-profile open source project. One of the biggest challenges we face is that Mozilla is a public benefit organization; this means that we don’t tend to drive the same scale of insane profits that some of our competitors do (and profits aren’t bad thing!), which means that we have to find new and interesting ways to scale; I spoke about some of these things at AppSecUSA at the end of October, and the video should be available online soon.

Adding to this challenge is the state of the Application Security workforce. For skilled AppSec people, the unemployment rate is essentially 0%. For under-skilled[1] AppSec people, it is not much higher; this provides the challenge of trying to recruit skilled, knowledgeable people to help with some of our activities. We have had a huge amount of success over the last two years in growing and building an effective team, but like every other security team, we are increasingly competing for a small number of high value individuals. (Hey, interested in applying for jobs? Look here!)

To even further complicate matters the amount of competition in the security space, and the history of the security community telling everyone that security sucks, security is hard, and they aren’t smart enough to get security right, have all contributed to the proliferation of Security As a Service vendors. Unless you have a huge amount of financial resources, compelling and interesting problems to work on, or some other incentive, it is very difficult to attract security talent when vendors are offering top dollar for people to work in their bug mills (again, not a bad thing; good quality teams are expensive, and vendors can help offer access to good talent).

What

For the last year I have been preaching automation to our team, and last spring we started growing our Security Automation Engineering team. Following that, we recently started to build out a new team to focus on developer oriented tools. We wanted an “security tool automation system”. We envision a tool that will provide basic automation for a range of security tools, with intelligently selected configurations for ease of use, and well thought out configuration options to allow the user to configure a range of tools by modifying a small set of values. This tool is called Minion.

Minion is intended to be disruptive.

First, it will help us break out of the pattern of running and using security tools within our team; we want all of the developers in our organization to use them. We want our developers to do horrible things to the applications and services they write, and we want it to be as easy as the push of a button. If my team is asked to review an application[2] for release to production, having passed through Minion should be one of the first steps.

Second, we want Minion to become a Security As A Service platform. Automation is not the answer to everything; In the long term, Minion should provide a solid toolkit that any security team can use to organize around. Once we finish the core feature set of Minion, we will start to focus on the team oriented aspects of the platform. It should be easy to extend, easy to adopt, and support hooking into each step of the SDLC. In short, we want to create a platform that allows any good security team to compete with the established Security As A Service players in terms of service delivery, documentation, and workflow, without constraining people to a specific philosophy or process.

Finally, we want Minion to be a framework. As an information gathering tool, it is effectively useless if that information feeds into a write-only repository. To that end we are working to define clear, extensible formats that can be used to integrate with and consume data from Minion. Want to create a fancy dashboard for C-Level executives? Minion should allow that. Want to write a module to automate generating a report worthy of a typical audit firm? Minion should allow you to do that! Want to perform data mining to find out vulnerabilities that are most common in the applications you test? Minion should allow that! By building Minion around REST APIs and modern web standards, it is possible to build any kind of mashup you can think of with the data that Minion collects and the results it tracks.

How

I pushed for Minion to be created, but it would still be a poorly written set of PoC scripts if it wasn’t for the hard work of Matthew Fuller, Simon Bennetts, and Stefan Arentz. These guys have done an amazing job, and I look forward to seeing how they continue to push the project forward! If you are interested in Minion, you can check out the repo, or join the mailing list using the links below!

Thanks for reading!

Yvan

[1] “Underskilled”: Securing web applications is hard. Securing applications is hard. Securing applications that people use to build web applications and access web applications is really hard. Not everyone is cut out for the job, and there is nothing wrong with that; there are a lot of opportunities for people that don’t demand staying on the bleeding edge of technology.

[2] Note that this is different from the consultative security work we do over the course of a project; Minion is not a substitute for a security program, it simply offloads some of the testing burden to automated tools and lays a foundation that the security team can look at when starting a final review before a product or service is released.

Speeding Up Security Reviews

This post is cross-posted from the Mozilla Security blog.

At Mozilla we have a strong commitment to security; unfortunately due to the volume of work underway at Mozilla we sometimes have a bit of a backlog in getting security reviews done.

Want to speed up your security review request? You can dramatically increase the turn around time for your security review request by providing the information below. In addition to this, we are working to expand our overall security review process documentation; you can follow those efforts here.

1. Architecture Diagram

An architecture diagram illustrates how the various components of the service communicate with one another. This information allows the individual doing the security review to understand which services are required, how and where data is stored, and provides a general understanding of how the application or service works. Producing an architecture diagram is a good practice as it allows anyone to get a rapid view of how complex a system is, and can inform how much time it will take to work through a review of the system.

Examples

Note that these are just examples; the architecture diagram is intended to help the reviewer visualize what they are assessing. It doesn’t have to be a fancy diagram, and our team has worked from camera shots of whiteboards from meetings!

2. Detailed Application Diagram

A Detailed Application Diagram is essentially a Dataflow diagram; a data flow diagram enumerates each application or service that is a component of a system, and provides a list of the paths that data can flow through. A dataflow diagram helps the security reviewer to understand how data moves through the system, how different operations are performed, and if detailed enough, how different roles within the system access different operations.

While there are a number of different opinions on the “best way” to do a DFD, it is more helpful to have the information than it is to focus on presenting the information “the right way”. Examples

3. Dataflow Enumeration

An enumeration of data flows in the application explains how and what data moves between various components. Note that this doesn’t need to be a rigorous explanation of fields; in this case we want a general description of the message, the origin of the message (browser, third party, service, database, etc), the general contents (e.g. “description of the add-on”, “content to be shared”, etc), and a list of sensitive fields. The BrowserID Dataflow Enumeration is an excellent example.

4. Threat Analysis

The next step is reviewing all of this information to build out a list of the threats to an application. The important bit here is that you, as a developer or contributor, know how an application or system works. You know what a good set of the failure modes of the application are, and you understand the ‘business logic’ of the application. Many developers have a working knowledge of vulnerabilities, and can identify these types of issues. In order to properly perform a threat analysis a reviewer needs to understand how the various components of the system work, what threats exist, and be able to identify what mitigating controls have been put into place. Here is an example of what a threat analysis might look like (links below):

he threat analysis should contain, at a minimum the following information:

  • ID – a identifier for the threat
  • Title – a concise description of the threat
  • Threat – a description of the threat
  • Mitigations – a recommendation for a control that can be implemented
  • Threat Agent – a list of the potential actors considered that would exploit a vulnerability
  • Notes – Related comments that contribute to the analysis, but don’t belong in other columns
  • Rating – A qualitative scoring for a vulnerability in the context of this application
  • Impact – A qualitative score representing the impact should a vulnerability be exploited
  • Likelihood – A qualitative score representing the likelihood of a vulnerability being exploited

Additional information on how we assess and rate threats will be published as part of the documentation for our risk rating and security review process. Examples:

Help us help you!

Part of determining the scope of a security review is understanding how an application works and what the risks are; the documentation described in this post helps us to understand this and will ensure that we can complete a security review as quickly as possible. Beyond that, as teams understand how security reviews are performed it gives them the opportunity to take ownership of security and build it more effectively into their own processes.

As with other Mozilla teams we are actively pursuing better community engagement and always welcome feedback.

Working in security I spend a fair amount of time reviewing and looking at work other people do. Turns out when you do that for 10 years, eventually people start seeing you like this:

While some of the things I have seen make [2] me feel that way, the reality is that I have tried to spend most of my career helping people to try to do things better, not to stop them doing new and cool things.

I have lost count of the number of times someone has said in a meeting “We can’t do that, security won’t let us!” with me sitting right there! Ok, fair enough, sometimes it’s true, but most of the time we are really trying to say “Not like that!”. You need a remote access solution? Sure, but lets but that RDP service behind a VPN. Need to install a new, untested web service on our domain? Ok, but why don’t we do some testing and maybe some fuzzing on it first. You want to ship all of our employee data to that 3rd party? Lets have a chat with them first so that we can make sure their security practices are reasonable first.

If I am talking to you about a security issue and you think I just said “No”, make sure you listen the rest of the “t like that!” because I am probably trying to help you[1]!

[1] The exception to the rule is if you are talking about PHP or Perl. Then I mean no.

[2] Circa 2016, I started to come around on WordPress, as the automatic update features and PHP’s overall maturity started to improve.

HR wants your password? Be careful…

There have been a number of articles recently covering the practice of prospective employers requesting access to social media sites, personal email accounts, or other deeply personal stores of information.

Despite this being an egregious violation of privacy, it is a growing practice, and one that requires clear guidance and regulation or legislation to protect users. The good news is that the tech industry doesn’t need to wait; most of the major players have clearly defined policies which forbid this practice.

Facebook asks its users to commit not to share their passwords or accounts as part of their “rights and responsibilities” which stands in place of the terms of service. LinkedIn has a similar requirement in theirs. I am not going to do an exhaustive survey, but it is highly likely that these terms are included in most others as well.

These service providers should clearly and publicly respond to this usage pattern and inform businesses that if they continue this unethical (and potentially illegal) activity, they will be blocked from accessing the services.

There is not much of a motivation for them to do so, but Social Media sites should also take technical measures to detect and actively warn users that are granting access to 3rd parties that they may be violating the terms of service.

A few strategic short-term bans on users who grant this type of access would create a a world of hurt for recruiters and compel users to refuse to participate in this behavior.

On Splitting Hairs…

This probably isn’t as constructive as it could be, but arguing that something is or isn’t a concern based on multiple definitions of a word is generally ineffective when the root cause of the argument is over the multiple definitions of the word.

“Without wanting to have the same arguments again (not the point of this thread), there are two overlapping uses of the verb ‘discriminate’.”

and

“I support the legal definition of marriage which is the voluntary union for life of one man and one woman to the exclusion of all others. I oppose any attempt to redefine it.”

Considering the source for the modern “legal” definition of marriage in most of the “Western World”, I think that is far to narrow an attempt to define it. For the judeo-christian perspective, please consult this handy chart:

Security Conferences are making me sad…

Over the course of my career I haven’t had the opportunity to attend many security conferences, for two reasons:

  • the organizations I worked for didn’t really support sending staff
  • I tend to be socially awkward, and have difficulty talking to people

When I started at Mozilla I was super excited about both attending and participating at conferences since not only could I actually attend them, but pretty much everything important that we do at Mozilla is done in the open! Since presenting and participating in security conferences would help me work on the social anxiety bit, and I would learn stuff, it was a huge win!

The conferences I attended several years ago left me inspired, excited, with a pile of ideas for problems to tackle, and tools to develop. The conferences I have attended in the last year have left me thinking “That was a really great rehash of stuff that has already been done to death, with a minor twist at the end.”

To a certain extent this is likely the result of the degree of advances in the field. Ground-breaking, revolutionary new attacks are going to become increasingly rare; you can read more about why here, but basically, IT Security and InfoSec is starting to mature as a research field. Another reason why is the increasing desire to extract direct value from security research; if it can’t be used for marketing, or sold explicitly in a vulnerability market, the it is a trade secret that can be rehashed as special consulting secret sauce. Coupled with the proliferation of security conferences of varying degree of quality, and the glut of “me too” presentations, I think this is going to get worse before it gets better (at least for offensively focused conferences)

Despite my concerns on this, I have continued to attend because I still want to build a better network; first, because sharing ideas and info is fun and cool, and second, because we have a bunch of neat open jobs, and talking to smart people about Mozillas mission and work is a great way to try to recruit people! Unfortunately this also makes me sad. At virtually every conference I have been to, it is virtually impossible for me to ‘meet people’ and ‘network’. I blame myself for this because of the reason listed above, but it is also the result of the cliquey nature of communities.

There are some exceptions to my conference malaise, and those were the BSidesSF events; even though the talks were less engaging[1] this year than they were in 2011. The BSides events were very interesting because although there were still cliques, they were easy to mix into. The groups were small, and the attitudes of people generally more positive, and everyone I spoke to was interested in chatting and getting to know people.

Rather than just complaining about it, I am going to try to do something about it. A few years ago I had the opportunity to present at a cool conference, but my employer at the time interfered. Now that Mozilla is actively promoting our mission, and supports pushing the security component, I am going to push hard to complete two distinct research projects over the next year, and aim to present the results and tools. Although either of the topics would likely be suitable for a major “mainstream” security conference such as BlackHat, RSA, (Can|Pac|Eu)Sec, I will aim to present at smaller regional conferences, or conferences that are focused on open communities such as MozCamp, OWASP, or BSides events.

My Projects

The first one builds on the Garmr tool that Mozilla released earlier this year, and will help security teams to perform low to moderate risk assessments at scale. I aim to present these application security tools at a conference in Q3 of 2012, with a tool release in late Q2 or early Q3. The focus of this tool will be implementing some the concepts and ideas I wrote about when I joined Mozilla, with the aim to enable teams to perform security work at scale.

The second one will be an attempt to combine some of the AppSensor / Attack Aware Application work that OWASP published with some really cool new technologies to take security event monitoring in a different direction. This is a joint project with another person and will not be ready until sometime in 2013.

I hope to see people at future conferences, and will continue to chip away at building a better network and meeting people, but I really hope that shifting focus can help me to recapture some of the inspiration I used to get from the security community!

[1] YMMV! Several of the talks touched on areas I have done work in the past, so there was not much new ground covered for me.

Voicing an Opinion

Mozilla is a fascinating place to work. I am surrounded by brilliant people who inspire me on a daily basis.

One of the great bits about brilliant people is that they usually have a some very well thought out opinions or beliefs, and most people tend to be very vocal about them. Because we are an open community at Mozilla, we also have many ways to share information, including Mozilla-hosted and personal blogs, social networking tools, etc, etc, etc, and we also host an aggregator for this content at planet.mozilla.org.

Yesterday a prominent member of the Mozilla community posted a call to action for his particular set of beliefs that was picked up by planet and shared with the entire Mozilla community, and a huge “discussion”[1] ensued.

“I may not agree with what you say, but I will defend to the death your right to say it.” – Voltaire

So let me be 100% clear. Gerv’s comments were his own. The are based on his world-view, and to many people, they are patently offensive and discriminatory. That said, Gerv has every right to voice his opinion. His opinion is offensive to liberal minded people, but suppressing offensive speech or writing is a dangerous first step to oppression. Consider this: if the gay rights movement, or the black civil rights movement, or the women’s rights movement didn’t have the advantage of freedom of speech, those nascent movements would have been killed before they accomplished the laudable goals they achieved.

Because the people who launched these movements in the west had (for the most part) the luxury of freedom of speech, the voices of the individuals who opposed the advancement of human rights were drowned out by the voices of those pushing for freedom and equality.

“A great many people mistake opinions for thought.” – Herbert Prochnow

Suppression of offensive opinions or beliefs (I hesitate to call them ideas, because it implies there is something innovative, new or original about the opinion) is not the correct approach. Keeping things in the dark is a great way to allow a subculture of hate and fear to grow, and silencing a hateful voice pushes it into hiding.

Do not silence someones opinion through censorship, instead, drown out the voices of hate and discrimination with shouts of support, and calls for equality and freedom.

And on an additional note, it is important to note that throughout the history of humanity, anyone who stands opposed to equality and human rights is on the wrong side of history.

[1] and by discussion, I mean shitstorm.

Cookies
We serve cookies. If you think that's ok, just click "Accept all". You can also choose what kind of cookies you want by clicking "Settings".
Settings Accept all
Cookies
Choose what kind of cookies to accept. Your choice will be saved for one year.
Save Accept all