Intellectual Property: A Useless Term

Commentary::Marketing
Audience::Entry
UUID: 3a061855-fa21-4efc-a0cc-494418698118

I mostly hate the term Intellectual Property (IP), because it is mostly useless. Copyright, patent, trademark, etc., law has little in common, anywhere in the world.  Personal and societal impacts of those laws are similarly disparate, as one would expect.

Now and then, something that seems to absolutely fly in the face of common sense (granting that sense does not seem to be common) is particularly grating. Such was the case with Definitive Guide (TM) to Cyber Threat Intelligence.

There are various regulatory (and attempts to self-regulate, in order to avoid actual regulation, such as PCI) regimes that require a lot of reading related to possible threats. Fine. Been doing it for years, because I regard it as necessary, and so I applaud that. But it is extremely time-consuming: the doc mentioned above is a 74-page PDF, and is only part of today's reading list. The madness that allows a common phrase to be trademarked is annoying as hell.

Still, one of the contexts that I'll be reading this in (and marking it up for future reference) is DevOps, where there might possibly be some insight to be had from Table 1-1. The first table, so I will have to read this entire pile of marketing nonsense, in case there is support for it later in the doc. There might be something relevant to more recent DevOps concepts (and other marketing nonsense that have been about it) as opposed to older security-related divisions (network, infrastructure, and security operations) within an organization, and their contributions at the 'Tactical, Operational and Strategic' levels. Never mind that tactical and operational divisions would seem very artificial.

So, 74 pages that is mostly marketing noise. Some of which is about banks, etc., being clients. I covered that above, writing about regulatory (and avoidance of same) requirements.

That DevOps reference? DevOps is also rife with marketing noise. But much of DevOps does promote ideas related to getting beyond some long-standing (and foolish) IT practices, such as throwing code over the wall. Which makes me far more tolerant of that group.

In the unlikely event that you have some twisted urge to read this doc too, it can be had from https://cryptome.org/2015/09/cti-guide.pdf. I'm not supplying a direct link to these people directly, for two reasons:

1. Zero desire to provide them any Google-juice.
2. I expect that some sort of registration would be required, hence you would be bombarded with email marketing for, roughly, forever.

If you never see another post on fubarnorthwest, it may be because reading

Chapter 7, "Selecting the Right Cyber Threat Intelligence Partner," enumerates criteria for evaluating cyber threat intelligence providers.

caused immediate brain-death.

Sometimes I Just Have to Rant

That is a failure on my part. I've been working on a set of three posts that would likely have been more helpful, that do not involve Intellectual Property, and would point readers toward things that are more useful, such as why I am about to recommend the Computer Laboratory, University of Cambridge.  Sorry about that. Coming soon.

Long Odds: 7,975 to 1 Against

Commentary::Statistics
Audience::Entry
UUID: df96273e-2da9-4d92-9b6d-cbdfdfb9b5c8

What went wrong by noon. So that you can say, "I am doing way better than that guy."

Waking up at 0430

That's 4:30AM to an unfortunate majority of my fellow citizens. Side note: we are one of a very few countries to use this system, and I hate it. It's harder to parse in software, etc. But leaving the side note firmly aside, waking up at 0430 sucks, unless you have some good reason for it. Which I did not. It just happened, so it sucked.

My month-old coffee maker decided to not make coffee

If I am up at 0430, a cup of coffee will usually sound like a truly fine idea. Grrr, and dig out the drip pot I use when I'm camping. It makes very good coffee, though not good enough to wade through warranty hassles. Because nothing is that good.

Discovered that it had not rained

You might think that no rain is a Good Thing, but then you might not be living in western Oregon, in a year that has set records for number of days above 90° F (I don't mind the Fahrenheit scale, because of better resolution). and an ongoing drought. There was rain in the forecast, but NOAA, as usual, blew it. I had been hoping to prep the ground for a new herb garden this evening, but that ground remains hard as stone.

The clothes dryer does not dry clothes

Forgot to toss wet laundry in last night, when I was working late (I work at least 90% from home), so I did it this morning. Motor runs, and it heats up. But the drum doesn't spin, unless you spin it by hand, which you should not be able to do. Great. Probably a belt has broken, or somehow come off of a pulley. Deal with it tomorrow, since I'm driving into town anyway, for another coffee maker. Because screw waiting for some random warranty process to complete: I'll donate the replacement to some worthy group.

Retreat to data analysis fails

The work projects were all well ahead of schedule, except for one new project that I didn't know the extent of. Fine. The sample is a series of small (all under 4 MB) flat files, and the usual approach for this sort of thing, under Linux, is to poke them with bash shell tools, before loading them into an iPython notebook, and doing the real analysis with the Pandas data analysis library. I went a bit too far in the bash stage, binning some things out with regular expressions in GNU grep. How many results are in a single-digit bin, versus a 10-19 bin?

It turned out that in the first file I examined the numbers were equal, which was, to put it mildly, unlikely. Of course, the now you have two problems RegEx issue came to mind, so I did a bit of staring at code, which revealed no bug. I checked the result three different ways, and found it to be accurate.

Then I did what I should have done to start with, given the way the day had gone far. I checked the other files, and found that this was the only file that generated equal numbers. Given the way the day had gone so far, I was biased toward looking for something else that had gone Badly Wrong, however unlikely, and I wasted time.

7,975 to 1 against

Those were the odds (calculated after the fact) against running into that particular scenario. What are the odds of the day, overall, having gone so incalculably wrong? I have no idea. Because incalculable. Duh. We lack crucial numbers on coffee maker (by manufacturer and model number) failure rates...

There's a well-known example of unlikely things happening on a daily basis. If you have a data source, look at how many cars are registered in your state/province/whatever. Then, next time you are doing some random drive, pick a license plate number, and calculate the odds of having seen it.

There are probably very long odds against it. If not, congratulations may be in order: you may have just had an opportunity to discover, in day-to-day life, how difficult randomness (the source of much cryptography) really is. Consider sources of error e.g. picking a plate close to home, at a time many of your neighbors leave for work, is going to skew your result.

A double-plus-good would arise from seeing such a failure of randomness, and gaining an insight into the power, for good or ill, of data mining.

Risk Transfer Failure: a Possible Example

Commentary::Risk
Audience::Intermediate
UUID: 2f7d104e-1066-4735-a1a7-c1c0f39882f4

In classic risk analysis, if such a thing can be said to exist, there are four categories of risk response.

1. Mitigate

2. Avoid

3. Transfer

4. Accept

where Transfer means transfer part or all of the risk by e.g. insurance, hedging, outsourcing, or partnering. This category is sometimes split into Transfer and Share, giving us five categories.

There are many things that can go wrong in assigning the probability/consequence numbers that drive which response category is chosen. But let us make the completely unwarranted assumption that those are all solved problems, and apply our imperfect solution to the risk of the loss of medical records. The choice to transfer risk is usually made when that risk is evaluated as low probability, but high consequence.

One assumes that this what Cottage Healthcare System did when they chose transfer the risk, via insurance, to Columbia Casualty Company in the form of a "NetProtect360" policy, as they are subject to HIPPA regulation, which amongst other things, requires a risk analysis.

Then, in 2013 32,500 records were stolen, and in a class action, they were sued by their customers for $4.125 million, which Columbia paid. Risk transferred, job done, mission accomplished, right? Well, no.

It turns out that when Columbia paid off on the policy, they reserved all rights, including the right to seek reimbursement. There was an ongoing Department of Justice investigation, which was entirely appropriate, as HIPPA is federal law, and it turns out that Cottage had done some things that were perhaps unwise, to put it mildly, such as placing those records on an Internet-facing anonymous FTP server. Given the current state of network scanning, which is best described as 'constant', this made the actual risk high probability, not low. It also became visible to Google, which made the breach a virtual certainty.

In applying for the policy, Columbia required a "Risk Control Self Assessment", which included such questions as "Do you have a way to detect unauthorized access or attempts to access sensitive information?" and "Do you control and track all changes to your network to ensure it remains secure?", to which Cottage ticked "Yes", and which then became part of the terms of the policy. Access via anonymous FTP is obviously not compatible with either of these.

HIPPA Bites Again

And now we are back to the DoJ investigation. The risk analysis required by HIPAA contains questions such as the following.

• §164.312(a)(1) Standard Does your practice identify the security settings for each of its information systems and electronic devices that control access?
• §164.312(a)(2)(i) Required Does your practice have policies and procedures for the assignment of a unique identifier for each authorized user?
• §164.312(a)(2)(i) Required Does your practice require that each user enter a unique user identifier prior to obtaining access to ePHI?

where ePHI means electronic Protected Health Information. Access via anonymous FTP is obviously a complete non-starter, and Cottage would seem to have violated Code of Federal Regulations Title 45. See 45 CFR 164.312 -Technical safeguards.

We Now Have a Partial Risk Transfer Failure

At the very least, legal fees are mounting. Columbia sought reimbursement in United States District Court, Central District of California. The case was dismissed without prejudice (meaning the issue can reappear) in July, because the policy also allows for resolution by mediation, and both parties have decided to pursue that approach first.

We may never know the degree to which risk transfer failed. Cottage is a not-for-profit, so some information may turn up in financials - a Form 990, or it may fail, and reappear in the courts. But mediation might drag on for quite a while, and I could miss the resolution.

I'm curious because at the moment public information on examples of risk transfer failure is rare. I expect that to change: insurance companies moved into this market some time ago, and they are growing tired of paying out potentially large (Target had $50 million in coverage, which may be insufficient) settlements, particularly where failures on the part of the insured seem provably fundamental and complete.

Takeaways

It seems possible, even likely, that was a rogue server installation. It happens: I've found an Internet-facing rogue myself, which contained sensitive information on a new product. The cause seems to generally be that there was some sort of perceived business emergency, it was supposed to be temporary, and there was a disconnect between operations and security. 

1- Compliance with the terms of an insurance policy must be included in security operations.

2- Whether you have transferred risk or not, pay attention to the fundamentals. Scan your network, and analyze traffic logs.

Also, while it isn't a takeaway from this specific example, be aware of the possible existence of so-called 'Shadow IT' within your organization. The server that bites may exist not in your DMZ, but in the cloud, funded by credit card. Administrative controls fail at least as often as technical controls.

Don't Roll Your Own Crypto: Examples

Commentary::Crypto
Audience::Entry
UUID: bb828445-8bfc-4ccf-835b-5fdfa181ffc6

The usual reason given for asking software developers to not roll their own crypto is that anyone can build a cryptosystem that they cannot themselves break. That is perfectly true, but there don't seem to be many concrete examples that might convince the unwary. I'd like to provide a couple.

What most people see are references to Secretary of Defense Donald Rumsfeld's there are known knowns response to a question (much laughter from media pundits), and more scholarly approaches, such as calling it the Dunning–Kruger effect (a cognitive bias) after their widely-quoted Unskilled and Unaware paper.

Lots of people in the security trenches think of it simply as some_random_person who doesn't know that they have no freaking clue. That's a bit unfair, because we all do this, to some degree – that's the nature of a cognitive bias. For example, many people who can actually write would consider my blog posts a prime example. A more appropriate example would be the (several) people I have met who do networking, including quite competent jobs of network architecture, who have never read an RFC, and have only a vague idea of what the Internet Engineering Task Force (IETF) is. In many areas of IT, one can get by perfectly well without deep knowledge. There are fewer such areas in security, and none at all in cryptographic design and implementation.

The IETF are a great example for me to use, because I generally like to make more people aware of their existence, and, in this specific case because I recommend the IETF Crypto Forum Research Group Discussion Archive - Date Index as the first of those concrete examples. Read a few threads, and you will hopefully realize that this is something best left to specialists – those who have a made a career of it.

If that doesn't do it, have a look at Introduction to Modern Cryptography, by Katz and Lindell. You can look inside the second edition on Amazon. The first edition was a game-changer because it widely introduced provable security: the notion that rigorous mathematical proofs of the properties of a cryptosystem were the way forward. Provable security is one of the few means by which cryptography may get past the invent-break-fix stage. Here's a search onBirthday Attack, in the first edition at Google Books. Katz maintains a page on the book linking to reviews, courses where the book is used as a text, and errata, as well as a page on the page on the second edition.

On my shelves, I have only the first edition of Katz and Lindell, from 2007. It impressed me enormously, and now there is a second edition. So why aren't I talking about that edition? Because I am in no way qualified to roll my own crypto, and can't take years to learn the subject. My opinion would be irrelevant, even if I had one. Again, it's a very specialized thing, and unless you are both extremely clever, and willing to devote the better part of a career to it, you really shouldn't go there.

Also, please be aware that provable security is about algorithms. Implementations of those algorithms is a whole different thing, and we as yet have no complete solution to the implement-break-fix cycle. Crypto code is often complex, not least because it needs to defend against things like timing attacks. That famous line about "all bugs being shallow, given enough eyeballs," certainly does not apply here, where the essential requirement are those very few highly qualified eyeballs. Hopefully auditing well-commented code. Let me remind everyone that Heartbleed was an implementation bug, in one of the most widely used protocols (TLS, though also DTLS) crypto libraries (openssl), yet it remained undiscovered for two years.

So, for the third time, don't go there. Because there is already enough suffering in the world. Your time will likely be far better spent along the following lines.

• understanding what you are trying to secure, and from whom
• the strengths and weaknesses of various crypto suites and algorithms
• their applicability to the problem you are currently facing
• their suitability on your intended deployment platform

About this lack of recent posts

Sorry about that. Well, not really. It's been due to a combination of several things. Some professional stuff that I can't talk about, but mostly because Oregon in the summer. I am pretty outdoors-oriented in my off time, and needed to take advantage of the weather, which will be turning Pacific Northwest bad, which is famously bad, soon enough. 

I expect that now that the long Labor Day weekend is over, the pace will pick up a bit. Standing on the deck sipping coffee at 0530 this morning, with a half moon in the east, and Orion and the Pleiades almost at zenith was great, though I was listening for owls, and didn't hear any. And it wasn't so long ago that sunrise was at 0530, and none of this would have been seen. At the Winter Solstice, when there are less than 9 hours of any light in the sky, and it's likely to be pouring rain during those brief hours, I'll probably be posting a lot more often. 

The Ashley Madison Breach Was Likely a Good Thing

Commentary::Breach
Audience::Entry
UUID: 4cf5d0bf-381b-4bc5-be2f-f31b8fb0d481

Unless you happen to be a victim, anyway. There is a large set of users who will trust their most sensitive secrets to some random Web site. That has been true since the Web was born, and it isn't going to change, save temporarily. This is one of those moments when a lot of people get outed, and the extent to which it damages them is likely proportional to both their perceived importance (celebrities are not intrinsically important people) and their foolishness.

We can expect a stream of celebrity 'exposures' as news agencies comb a large data dump. Meh. Much noise, signifying nothing. Though I do not doubt that security vendor marketing departments of one sort or another are grinding their heads trying to come up with a way to peddle another White Paper.

The threat, minimal though it is, lies in having someone within your organization who is doubly foolish. Enough to trust that random Web site to begin with, and now willing to do silly things, in the hopes that they will not be outed via what is a very public data dump. In other words, victims of extortion, waiting to happen.

The outcome of that could be very bad indeed. But it really isn't very likely, despite what IT press might indicate.

Take The Register, for example. Always a favorite amongst many IT folk, for the headline comedy, if nothing else. They are unabashedly, well, flamboyant. Now Ashley Madison hackers leak CEO's emails, source code As IBM, Cisco and HP lead the IT pack on adultery website, it seems. They have a couple of bar charts. The first might be of interest to sociologists, as it's about Attached Male Seeking Female, etc. Though one would hope that even practitioners of the soft sciences would do their own research. The second graph is even better. 'Number of Valid Ashley Madison Accounts Among the Largest Tech Companies'. The winner is IBM, with 311. Oh, noes! Until you realize that this is out of a headcount of 379,592 employees at the end of 2014, according to Bloomberg. Eight hundredths of one percent. I doubt that the IBM risk management team is sweating this, and you likely shouldn't either.

What is more likely, in my opinion, is that unteachable people are the greater threat. Those unfortunate people who fall for every phishing scam, click any link in email from strangers, can't exist without a years-old version of Adobe Flash, etc. Yeah. Those people.

Who, by the way, are not mentally deficient, and if you are one of those people making snide remarks referring to 'lusers' instead of 'users', you are part of the problem. If you are heard making a remark like that as you make your way through the cube-farm, you have just alienated the people you are supposed to helping. It's unprofessional, and hasn't been funny for twenty-odd years.

A large subset of the workplace population have certain characteristics that may make a security worker's life more difficult.

1. An inherently trusting nature
2. Not comprehending the nature of the environment
3. Exclusive focus on the task at hand

There's nothing you can do about 1, save waiting for life to burn them enough times for them to develop the required amount of cynicism. Which it undoubtedly will. Number 2 is usually teachable, provided you have not blown any chance of building a rapport via 'luser' comments, etc. Number 3 involves a certain amount of irony, in that we often admire people who can get to that level of focus, and refer to it as in the zone, flow state, etc. That's my personal Happy Place, so I'm sympathetic. Their managers will likely value these employees, because duh. They are very productive.

So there you have it. 2 and 3 mean teaching, which is mind-boggling more effective if you can establish a rapport. 1? We're back to my title. The Ashley Madison Breach Was Likely a Good Thing. IT touches everything these days, from Wall Street to the local tire company. The chances are probably good that the legions of celebrity gossip fans, whom you probably never hoped to reach, will in some way be influenced by this.

How is that not a win?

Some Remarks About the Hacking Team Hack

Commentary::Disclosure
Audience::All
UUID: 90e9fc07-e6ab-454d-8265-48876691db93

I have to say, right up front, that I haven't been tracking this too closely. Things have been too busy (with things that I can't write about) for me to do more than follow a bit of the trade press, and do some very minimal exploration. Plus,  it's a bit odd to be doing two posts is a row (7/15/15 update: almost in a row. There is one post between this one and Does the Navy Buy Vulnerabilities Too?) on disclosure. That's a topic that could use a flight of posts, but creating that would require more effort than I am able to supply, given that I regard fubarnorthwest as a sort of twisted alien mutant from the Forbidden Zone hobby, not a business tool. And again, things are busy.

Finding trade press articles is obviously not difficult; it's a huge story. My position is that too much following of trade press is counterproductive. I use various criteria for classifying sources into tiers. A current example would be breathlessly wondering about whether or not a pre-announced TLS bug is "the next Heartbleed." No, it isn't. You can tell, without the bother of reading the story, because it was pre-announced. Too much of that crap gets a source downgraded. More information on how I rate sources is a subject for a future post, but not something with a high priority. If you are curious about it, tell me.

That said, Ars Technica has done solid trade press work on this, with a flight of articles. I'm only going to mention a couple here. But they are all linked in some fashion, so navigation shouldn't be a problem.

Article the First

Hacking Team’s Flash 0-day: Potent enough to infect actual Chrome user
Government-grade attack code, including Windows exploit, now available to anyone.
by Dan Goodin - Jul 10, 2015 2:00pm PDT
http://arstechnica.com/security/2015/07/hacking-teams-flash-0day-potent-enough-to-infect-actual-chrome-user/

I'm going to ignore the "Potent enough to infect actual Chrome user" bit, save to note that browsers are inherently dangerous, and Chrome had unpatched vulnerabilities on the day it was launched, back in August of 2008, because it was built on an older, exploitable version of WebKit. Implicit trust in a Web browser, from any supplier, is a Really Bad Idea.

Have a look at the lead graphic in this article. The one with the caption that says, "A browser-detection script that was part of a Hacking Team Flash zero-day exploit used in an Egyptian campaign."

That is Python, and it is being used to differentiate between Google Chrome and Microsoft Internet Explorer. The thing is, Python is rarely found on Windows systems. The simplest explanation is that Hacking Crew shipped a Python runtime for Windows. Bulky and noisy, but perhaps they just loves them some Python. I know I do. But it seems more likely that in a reasoned analysis, they find it advantageous. I tracked down the source code behind the graphic. This site is under heavy load as I write this, but it is available from https://ht.transparencytoolkit.org/gitlab/Windows-Multi-Browser/deliverables/scout_appended/resources/chrome_non_chrome_filter.py.

We can also infer something about their Python development environment -- that it is built around iPython notebooks. Again, no surprise. I use them too. The clue is (again, heavy load warning) 

https://ht.transparencytoolkit.org/gitlab/Windows-Multi-Browser/deliverables/scout_download/Reame.md. This is a  Markdown file, and it's one of the basic capabilities of iPython notebooks. Not least because you can dress them up with CSS to create elegant documentation. This tends to confirm (not that this is really necessary) that this was a business that paid a good deal of attention to business processes. Such as producing better doc, faster, and cheaper. As I do, and you should. If even the Bad Guys (and Hacking Crew are purely mercenary) are seizing that business advantage, and you aren't, why not?

Article the Second

Firefox blacklists Flash player due to unpatched 0-day vulnerabilities
Also, Facebook calls for Flash end-of-life, so that we can "upgrade the whole ecosystem."
by Sebastian Anthony (UK) - Jul 14, 2015 6:45am PDT
http://arstechnica.com/security/2015/07/firefox-blacklists-flash-player-due-to-unpatched-0-day-vulnerabilities/

I have had my Security Guy hatred on for Adobe products since, well, forever. Was that justified? There are ample reasons for not trusting the track record of a bit software, vis-a-vis a previous track record, as in any way an indicator of the future. To a point. The number of vulnerabilities appearing in CVE or other databases, etc., are all very flawed mechanisms. Papers have been written about it (no, not White Papers, but Real Papers), presentations have been given at security conferences (there are a couple of people I need to contact about this before I say more), etc. And there are some possibly better indicators, such as static code analysis.

Again, we can only make allowances to a certain point. Even if one considers that such software as Flash, running on Windows, is an almost universally installed target, and will receive a disproportionate amount of attention from exploit creators. We may, just possibly, be reaching a point where consumers are just fed up with the constant (FUBAR) state of Adobe Flash, and alternatives to Flash exist. Adobe Flash has had a very human cost in terms of stolen funds, identities, personal information, etc.

In future, I hope to call out those sites that still require Flash, in the hopes that it will just freaking die before more damage is done. I have two browser updates waiting for me on this system. Both are probably about Flash -- Google Chrome is making changes as well. Fine. Of the four Web browsers I use regularly, Chrome is the only one that can run Flash. If I approve it, on a case-by-case basis.

Aaaaaaand Now I Have to Go

Because Oracle (another purveyor of crap software) has just released their quarterly Critical Patch Update. http://www.oracle.com/technetwork/topics/security/alerts-086861.html.

There is at least one more important post in the Ars Technica flight of stories, but I have to defer that. Things just got busier. Thanks, Oracle.

What and When means better support and software

Recommendation::Documentation
Audience::Entry
UUID: cd1d2cf8-266a-11e5-8834-00224d83fb0a

Finding help for a problem in the Open Source world often involves search engines, filtering out random rants, and all too often finding something that does not work, as it was only appropriate four years ago. Which is I put publication dates at the top of my infrequent posts.

This is a problem in my older notes files, of which there are many.
$ find $notes -type f | wc -l
1277
It's not uncommon to find something that dates back ten years. It isn't a horrible problem, as modification times are in the files, so it's easy to spot. And no, I am not going to put that whole hierarchy under version control. Currently, it's too much overhead, given the way that I use that hierarchy.

For the past several years, I've dealt with the applicability issue with a shell alias in my .bashrc.
daterel() {
    date; cat /etc/redhat-release
}
$ daterel
Thu Jul  9 10:21:16 PDT 2015
Fedora release 21 (Twenty One)
I just paste the output into the doc. Or the bug report, or whatever. I recommend it to clients who are sending me bug reports, and some form of it is pushed to everything in the lab. I say 'some form' because in certain situations it may make more sense to output on a single line, change the date format to seconds since the epoch, or whatever.

Some variant of /etc/*-release is available in most Linux distributions, not just the families related to Red Hat (CentOS, Fedora, etc.). It might take other forms, such as /etc/lsb-release. Or even /etc/issue. And no matter which side of the systemd controversy you might fall on, it has at least provided /etc/os-release. Though that provides 'ANSI_COLOR=' which gets very near to one of my pet hatreds.

It might even take the form of a command, such as  'lsb_release <options>'
http://www.freedesktop.org/software/systemd/man/os-release.html. I note that freedesktop.org has done a Bad Thing here, though, in that they have made CPE_NAME= optional. Common Platform Enumeration is a standard worth supporting, if you ever expect to be glueing the output of disparate
security information and event management (SIEM) tools together.

It's not really complicated

Really. To the beginner, it might seem that way, but it really isn't. 

1. Search for files in /etc/, such as /etc/*-release. or /etc/issue
2. Search for commands, via something like 'which lsb_release'
3. Look at the results
4. Spend about 10 minutes thinking about it
5. Drop in a shell alias, or a quick script (in your $PATH, so it Just Works)
6. Profit! Better docs, better bug reports
7. There is no 7